5 ms·

Please use more readable names in your code. Use of names like 'fs' in key places makes it unreadable.

schrototo 14y ago
Generally this is of course good advice, but in Haskell it is common practice to use very short names (e.g. x, x', xs, ...) if the context is clear (which it usually is due to small scope, clear function names, type signature, etc.). This makes code much more concise and readable (it also makes it look very "mathematical").
- skrebbel 14y ago
  > (it also makes it look very "mathematical") Has that ever been an advantage?
  - psionski 14y ago
    For people that like math, sure, why not. When implementing mathematical concepts, if you squint at Haskell code you can see the original formulas, which should make it easier for people used to this way of thinking. EDIT: I'm not implying it's useful just for programming "math stuff", after all, everything can be reduced to a mathematical problem - including game engines[1], web application frameworks[2], etc. [1] http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf [2] https://github.com/yesodweb/yesod https://github.com/yesodweb/yesod
    - vidarh 14y ago
      And it's probably one of the most significant things limiting adoption of Haskell.
      - spiffistan 14y ago
        Indeed.
      - egeozcan 14y ago
        Exactly. From my point of view, Haskell is the perfect language which unfortunately comes with the worst naming conventions. (I generally develop in C#, F# and JavaScript)
        psionski 14y ago
        The naming conventions are fine, but they're very different from C#, F# or JS - it's basically the difference between reading English text and reading formulas (i.e. compositions of weird letters and symbols).
        psionski 14y ago
        I just want to add something - using Haskell's naming conventions in C# or JS is a crime against humanity. If your function is longer than 5-6 lines and wider than 10-15 characters `xs` or `<|>` are not good names. I think you could get away with it in F#, but it will look weird.
tel 14y ago
The convention for Haskell is to keep the active scope of variables very small. Any variable with an active scope of larger than maybe 3 lines, I make longer. Since these examples were hardly longer than that, I feel quite justified with short names. In Haskell, if you see a short name, look up and down 3 lines for the definition. If you can't find it then complain.
- dchichkov 14y ago
  I think you are right, and it is a convention in the functional world. People are using (and worse, reusing in a close proximity!) meaningless names like that. And I think these people have zero regard to anyone who is reading their code. Well... more power to python, and culture that embraces 'what your see is what your get' and super-readable code.
  - cscheid 14y ago
    There is actually an interesting technical reason for having short names in generic Haskell functions. Because of parametricity, the behavior of the function doesn't depend on what the values actually are. The shortness of the names really is meant to convey "don't think about what this is doing, because it's not important for this function". In the traditional example for map, map f [] = [] map f (x:xs) = f x : map f xs You're supposed to infer from the short function names that f and x could be anything. The only important bit is that you can apply one argument to f (so, for example, f could take two parameters, and then map is just doing a single partial application). In that context, x and xs is actually a better convention than "first" and "rest", because they indicate the adherence to the type system. The naming here is saying that x is of the type of elements of xs, and that this is the only important information for map. This seriously helps in more complicated functions like zip, etc.
    - dchichkov 14y ago
      I'm not so sure that briefness and adherence to that convention improves readability. Of course f, x, xs is much much better than 'first' and 'rest', or 'a', 'b', 'c', but something like 'func' and 'iterable' gives more context. And frees one's attention to more important things, than looking up and down the code. Compare: map f [] = [] map f (x:xs) = f x : map f xs With: map f xs = [f x | x <- xs] Or even better, in Python: map = lambda func, iterable: [func(x) for x in iterable] Which one is more readable? First one requires looking up and down in order to understand what is going on. Second one is better, context is limited to one line. And the last one doesn't require you to remember context at all.
deleted 14y ago
[deleted]

Generally this is of course good advice, but in Haskell it is common practice to use very short names (e.g. x, x', xs, ...) if the context is clear (which it usually is due to small scope, clear function names, type signature, etc.). This makes code much more concise and readable (it also makes it look very "mathematical").

skrebbel 14y ago
> (it also makes it look very "mathematical") Has that ever been an advantage?
- psionski 14y ago
  For people that like math, sure, why not. When implementing mathematical concepts, if you squint at Haskell code you can see the original formulas, which should make it easier for people used to this way of thinking. EDIT: I'm not implying it's useful just for programming "math stuff", after all, everything can be reduced to a mathematical problem - including game engines[1], web application frameworks[2], etc. [1] http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf [2] https://github.com/yesodweb/yesod https://github.com/yesodweb/yesod
  - vidarh 14y ago
    And it's probably one of the most significant things limiting adoption of Haskell.
    - spiffistan 14y ago
      Indeed.
    - egeozcan 14y ago
      Exactly. From my point of view, Haskell is the perfect language which unfortunately comes with the worst naming conventions. (I generally develop in C#, F# and JavaScript)
      - psionski 14y ago
        The naming conventions are fine, but they're very different from C#, F# or JS - it's basically the difference between reading English text and reading formulas (i.e. compositions of weird letters and symbols).
        psionski 14y ago
        I just want to add something - using Haskell's naming conventions in C# or JS is a crime against humanity. If your function is longer than 5-6 lines and wider than 10-15 characters `xs` or `<|>` are not good names. I think you could get away with it in F#, but it will look weird.

tel 14y ago

The convention for Haskell is to keep the active scope of variables very small. Any variable with an active scope of larger than maybe 3 lines, I make longer. Since these examples were hardly longer than that, I feel quite justified with short names. In Haskell, if you see a short name, look up and down 3 lines for the definition. If you can't find it then complain.

dchichkov 14y ago
I think you are right, and it is a convention in the functional world. People are using (and worse, reusing in a close proximity!) meaningless names like that. And I think these people have zero regard to anyone who is reading their code. Well... more power to python, and culture that embraces 'what your see is what your get' and super-readable code.
- cscheid 14y ago
  There is actually an interesting technical reason for having short names in generic Haskell functions. Because of parametricity, the behavior of the function doesn't depend on what the values actually are. The shortness of the names really is meant to convey "don't think about what this is doing, because it's not important for this function". In the traditional example for map, map f [] = [] map f (x:xs) = f x : map f xs You're supposed to infer from the short function names that f and x could be anything. The only important bit is that you can apply one argument to f (so, for example, f could take two parameters, and then map is just doing a single partial application). In that context, x and xs is actually a better convention than "first" and "rest", because they indicate the adherence to the type system. The naming here is saying that x is of the type of elements of xs, and that this is the only important information for map. This seriously helps in more complicated functions like zip, etc.
  - dchichkov 14y ago
    I'm not so sure that briefness and adherence to that convention improves readability. Of course f, x, xs is much much better than 'first' and 'rest', or 'a', 'b', 'c', but something like 'func' and 'iterable' gives more context. And frees one's attention to more important things, than looking up and down the code. Compare: map f [] = [] map f (x:xs) = f x : map f xs With: map f xs = [f x | x <- xs] Or even better, in Python: map = lambda func, iterable: [func(x) for x in iterable] Which one is more readable? First one requires looking up and down in order to understand what is going on. Second one is better, context is limited to one line. And the last one doesn't require you to remember context at all.

deleted 14y ago

[deleted]