As a programmer, I find myself struggling with a lot of really mundane and stupid-looking issues like "how should I name my variables", or "should acronyms be kept upper case (XML), or smooshed down for easier CamelCasing (Xml)?" and finally "what order should my code go in?"
These questions do not so much keep me up and night, but cause me an inordinate amount of flip-flopping in my code. Not
remembering my preference du jour, I'll sometimes do things four different ways in code and later on suffer because I forgot that in one bit of code, I had named something
parseXML and in the other bit, I had named it
xmlParse.
The good news is that things are settling down on at least one front. It seems that all the versions of Eric past and present are settling on a consensus on How To Lay Code Out. The result is a set of directional tips, akin to the kind of thing you learn when you are writing Chinese Hanzi (Japanese Kanji):
- Types before code
- High-level before low-level -- For example, generally using
where instead of let...in, but also "higher-level" functions first, "detail" functions later - Input before output -- It's not that this was ever up for debate, it's just that sometimes, I'll write it the other way without realising that I'm doing it.
- Odds and ends last -- At the very end of my code: an odds-and-ends section for all those little snippets of code you copy around but are that too small to justify making a library, e.g.
buckets :: Ord b => (a -> b) -> [a] -> [ (b,[a]) ]
buckets f = map (\xs -> (f (head xs), xs))
. groupBy ((==) `on` f)
. sortBy (compare `on` f)
Do you have an odds-and-ends.hs file on your computer?
Notice that the tips are not always compatible with each other, but they do sort of point in the same general direction.
Phew, I'm glad I'm starting to get at least this bit sorted. I really hope it reduces the amount of pointless erician flip-flopping. It's no big deal -- civilisation does not collapse because of inconsistent case conventions -- but it is a nuisance. This kind of thing is on the order of silly American-style dates vs. European-style dates causing confusion, where we could all just be using International yyyy-mm-dd dates, and while we're at it, 24 hour time, the metric system and A4 paper...
As a programmer, I find myself struggling with a lot of really mundane and stupid-looking issues like "how should I name my variables", or "should acronyms be kept upper case (XML), or smooshed down for easier CamelCasing (Xml)?" and finally "what order should my code go in?"
These questions do not so much keep me up and night, but cause me an inordinate amount of flip-flopping in my code. Not
remembering my preference du jour, I'll sometimes do things four different ways in code and later on suffer because I forgot that in one bit of code, I had named something
parseXML and in the other bit, I had named it
xmlParse.
The good news is that things are settling down on at least one front. It seems that all the versions of Eric past and present are settling on a consensus on How To Lay Code Out. The result is a set of directional tips, akin to the kind of thing you learn when you are writing Chinese Hanzi (Japanese Kanji):
- Types before code
- High-level before low-level -- For example, generally using
where instead of let...in, but also "higher-level" functions first, "detail" functions later - Input before output -- It's not that this was ever up for debate, it's just that sometimes, I'll write it the other way without realising that I'm doing it.
- Odds and ends last -- At the very end of my code: an odds-and-ends section for all those little snippets of code you copy around but are that too small to justify making a library, e.g.
buckets :: Ord b => (a -> b) -> [a] -> [ (b,[a]) ]
buckets f = map (\xs -> (f (head xs), xs))
. groupBy ((==) `on` f)
. sortBy (compare `on` f)
Do you have an odds-and-ends.hs file on your computer?
Notice that the tips are not always compatible with each other, but they do sort of point in the same general direction.
Phew, I'm glad I'm starting to get at least this bit sorted. I really hope it reduces the amount of pointless erician flip-flopping. It's no big deal -- civilisation does not collapse because of inconsistent case conventions -- but it is a nuisance. This kind of thing is on the order of silly American-style dates vs. European-style dates causing confusion, where we could all just be using International yyyy-mm-dd dates, and while we're at it, 24 hour time, the metric system and A4 paper...
haskell-ji
