Here's a simple issue that's been with me for a while. As do many people, I use plural variable names for lists, so if a Block as called 'block' then [Block] is 'blocks'. The other pattern that comes up a lot is 'Maybe Block'. When I have to name it, I call it 'maybe_block', e.g. maybe_block <- lookup something case maybe_block of Just block -> ... However, this maybe_ prefix is rather long and unwieldy. I have considered things like 'm' or 'mb' but they don't suggest Maybe to me. An 'm' prefix or suffix is already implying 'monad'. If '?' were allowed in identifiers I could use it as a suffix. I could just append 'q' and get used to it... lispers did it with 'p' after all. I suppose 'mby' could be ok, but for some reason it just looks ugly to me. 'opt' looks ok, I suppose, but 'optional' doesn't cover the full range of Maybe's usage (i.e. it's strange to call a failed lookup result "optional"). Does anyone else have a nice convention for this? Hopefully something short but intuitive and nicely reading like the plural convention?
In my own code, I usually use a 'mb' prefix with camelCase, like so: case mbStr of Just str -> ... Nothing -> ... But I agree that it doesn't always look very nice. I'm curious what others do. On Apr 22, 2011, at 1:14 PM, Evan Laforge wrote:
Here's a simple issue that's been with me for a while. As do many people, I use plural variable names for lists, so if a Block as called 'block' then [Block] is 'blocks'.
The other pattern that comes up a lot is 'Maybe Block'. When I have to name it, I call it 'maybe_block', e.g.
maybe_block <- lookup something case maybe_block of Just block -> ...
However, this maybe_ prefix is rather long and unwieldy. I have considered things like 'm' or 'mb' but they don't suggest Maybe to me. An 'm' prefix or suffix is already implying 'monad'. If '?' were allowed in identifiers I could use it as a suffix. I could just append 'q' and get used to it... lispers did it with 'p' after all. I suppose 'mby' could be ok, but for some reason it just looks ugly to me. 'opt' looks ok, I suppose, but 'optional' doesn't cover the full range of Maybe's usage (i.e. it's strange to call a failed lookup result "optional"). Does anyone else have a nice convention for this? Hopefully something short but intuitive and nicely reading like the plural convention?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I do it in a similar way, not just for maybes: paramMay <- getHTTPPostParam "Param" paramStr <- maybe (throwError "No Param parameter") return paramMay let paramE = parseParam paramStr param <- case paramE of Left e -> throwError $ "Error while parsing Param: " ++ show e Right p -> return p It'd be great, if there was a "centralised" naming convention guide. 22.04.2011 23:21, Matthew Steele пишет:
In my own code, I usually use a 'mb' prefix with camelCase, like so:
case mbStr of Just str -> ... Nothing -> ...
But I agree that it doesn't always look very nice. I'm curious what others do.
On Apr 22, 2011, at 1:14 PM, Evan Laforge wrote:
Here's a simple issue that's been with me for a while. As do many people, I use plural variable names for lists, so if a Block as called 'block' then [Block] is 'blocks'.
The other pattern that comes up a lot is 'Maybe Block'. When I have to name it, I call it 'maybe_block', e.g.
maybe_block <- lookup something case maybe_block of Just block -> ...
However, this maybe_ prefix is rather long and unwieldy. I have considered things like 'm' or 'mb' but they don't suggest Maybe to me. An 'm' prefix or suffix is already implying 'monad'. If '?' were allowed in identifiers I could use it as a suffix. I could just append 'q' and get used to it... lispers did it with 'p' after all. I suppose 'mby' could be ok, but for some reason it just looks ugly to me. 'opt' looks ok, I suppose, but 'optional' doesn't cover the full range of Maybe's usage (i.e. it's strange to call a failed lookup result "optional"). Does anyone else have a nice convention for this? Hopefully something short but intuitive and nicely reading like the plural convention?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Fri, 22 Apr 2011, Evgeny Tarasov wrote:
I do it in a similar way, not just for maybes:
paramMay <- getHTTPPostParam "Param" paramStr <- maybe (throwError "No Param parameter") return paramMay let paramE = parseParam paramStr param <- case paramE of Left e -> throwError $ "Error while parsing Param: " ++ show e Right p -> return p
It'd be great, if there was a "centralised" naming convention guide.
Of course, naming will always be a matter of taste. For instance I would not write maybe_something, because I prefer camel case, that is, maybeSomething. On the other hand, I already wrote some Wiki articles that you may read as suggestions for certain naming conventions: http://www.haskell.org/haskellwiki/Qualified_names http://www.haskell.org/haskellwiki/Pairs_of_identifiers and other articles in Category:Style. You may add an article for suggestions of how to name lists, maybes, eithers etc.
Of course, naming will always be a matter of taste. For instance I would not write maybe_something, because I prefer camel case, that is, maybeSomething. On the other hand, I already wrote some Wiki articles that you may read as suggestions for certain naming conventions: http://www.haskell.org/haskellwiki/Qualified_names http://www.haskell.org/haskellwiki/Pairs_of_identifiers and other articles in Category:Style. You may add an article for suggestions of how to name lists, maybes, eithers etc.
WRT to camel vs. underscores, I think it's mostly orthogonal, because you can always convert between them: mbX or mb_x. Of course a nice thing about the trailing 's' is that it's the same for both. I wish I had ideas for the other types... when there isn't something more descriptive, I just concatenate pairs, e.g. [(Code, Name)] becomes code_names (codeNames for the camels). Eithers I don't have to name often, but I do the same concatenation. Maps are key_to_val, or just to_key (then 'lookup key to_val' reads nicely), or by_key, or sometimes plural like "vals", depending on the context. Sets I use plural like lists. For functions, 'is_' for predicates, like many other languages. '_of' for projections. Of course for the variables, often the nicest is to avoid the name entirely by giving it directly to some combinator. If we had the 'lambda case' or monadic case then I could get rid of a lot of my 'maybe_' names. Hmm, maybe I do have some opinions :) Sounds like 'mb' is pretty widespread, and it seems like something I could get used to, so maybe I'll start using that.
Hi Evan The EHC compiler code base seems to use mbSomething as a convention. As EHC has quite a lot of textual information in its source - the code is Haskell + attribute grammars + Shuffle + plus more - the mb convention seems to work well and I adopted it for myself after seeing it there. These days I do like all lower case for variables though (unless the variables are functions and need better names than f g or fn). Best wishes Stephen
Well, Maybe IS a monad, so I just use "m" prefix.
Отправлено с iPhone
Apr 22, 2011, в 21:14, Evan Laforge
Here's a simple issue that's been with me for a while. As do many people, I use plural variable names for lists, so if a Block as called 'block' then [Block] is 'blocks'.
The other pattern that comes up a lot is 'Maybe Block'. When I have to name it, I call it 'maybe_block', e.g.
maybe_block <- lookup something case maybe_block of Just block -> ...
However, this maybe_ prefix is rather long and unwieldy. I have considered things like 'm' or 'mb' but they don't suggest Maybe to me. An 'm' prefix or suffix is already implying 'monad'. If '?' were allowed in identifiers I could use it as a suffix. I could just append 'q' and get used to it... lispers did it with 'p' after all. I suppose 'mby' could be ok, but for some reason it just looks ugly to me. 'opt' looks ok, I suppose, but 'optional' doesn't cover the full range of Maybe's usage (i.e. it's strange to call a failed lookup result "optional"). Does anyone else have a nice convention for this? Hopefully something short but intuitive and nicely reading like the plural convention?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 4/22/11 1:14 PM, Evan Laforge wrote:
Here's a simple issue that's been with me for a while. As do many people, I use plural variable names for lists, so if a Block as called 'block' then [Block] is 'blocks'.
The other pattern that comes up a lot is 'Maybe Block'. When I have to name it, I call it 'maybe_block', e.g.
maybe_block<- lookup something case maybe_block of Just block -> ...
However, this maybe_ prefix is rather long and unwieldy. I have considered things like 'm' or 'mb' but they don't suggest Maybe to me. An 'm' prefix or suffix is already implying 'monad'.
I tend to use 'm', but you're right that it causes confusion about whether mFoo is "monadic foo" or "maybe foo". Perhaps I should start using 'mb' instead...
If '?' were allowed in identifiers I could use it as a suffix.
I'd love it if '?' were allowed as an identifier suffix, though the lispers will assume it's a predicate rather than a maybe. While we're at it, three cheers for allowing '!' as an identifier suffix for indicating strictness (because the apostrophe has plenty of other uses). -- Live well, ~wren
participants (7)
-
Evan Laforge -
Evgeny Tarasov -
Henning Thielemann -
Matthew Steele -
Miguel Mitrofanov -
Stephen Tetley -
wren ng thornton