4 ms·

Don't get cute. Code golf is for competitions, not production code. Even if something takes 10 lines that you can do in 1, if 10 lines is clearer, do it that wa

by hvs 10y ago

Don't get cute. Code golf is for competitions, not production code. Even if something takes 10 lines that you can do in 1, if 10 lines is clearer, do it that way (you'll thank yourself in 6 months when you have to figure out what you were doing). Keep your functions to one or two pages. Keep your nesting to three levels, preferably two. If you have multiple nested if/while/for sections, break them up. (See: "cyclomatic complexity"). Follow the coding conventions of the project you're working on, even if you disagree with them, consistency is more important.

0xfaded 10y ago
Caveat, don't be afraid to use advanced language features if doing so eliminates boilerplate.
- fhood 10y ago
  Caveat Ruby's advances features seem to be designed to make code less readable sometimes.
  - 0xfaded 10y ago
    Changing the interpreter's behavior is equivalent to creating a new language. The problem with Ruby (and especially rails) programs is that every program is written in a different language, and what that language is is largely defined by external imports. I have no idea how people have the mental capacity to deal with this.
ScaryRacoon 10y ago
Readable code > cleaver code
tzs 10y ago
> Don't get cute. Code golf is for competitions, not production code. Even if something takes 10 lines that you can do in 1, if 10 lines is clearer, do it that way (you'll thank yourself in 6 months when you have to figure out what you were doing). Brian Kernighan put it well: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
- B1FF_PSUVM 10y ago
  The other bit I know, besides this one, is to write comments stating what you're trying to achieve, and why. The how is redundant, but sample data right there may help. (Someone famously pleaded for documenting the data structures, and leaving aside the processing mechanics.)
heurist 10y ago
Clever is the enemy! Simplicity is key.
bordercases 10y ago
> Don't get cute I struggle with this. I don't necessarily write a lot of one-liners, but recently I solved a document parsing problem using regex, list comprehensions, zips, etc; generally what are considered "clever" language features to my peers. The problem-solving approach seemed straightforward enough: match labels, slice document, destruct into keys and values into separate list, transform into proper formats and eliminate errors, combine into list of tuples. I could repeat this pattern because the document was structured hierarchically. On one hand, I believe that by using these methods I've written code that is maintainable and less sloppy, and reflects the strongest understanding of the problem. I personally find these language features empowering when I solve the problem. On the other hand, because these features are not the simplest features, the learning curve for interpreting the code is higher. I didn't use any obfuscation methods to compress the code, but neither did I apologize for the usage of the above. What I wonder is: if we don't try to leverage higher-level language features, do we end up defaulting to a brute-force approach with is less contained and raise technical debt? You could hedge around this through liberal commenting, but I find it difficult to believe that avoiding thinking about the problem as being too "clever" is much better. Somewhere there must be a compromise.
- pklausler 10y ago
  Rule of thumb: Any language feature or library API that is clearly and unambiguously documented, not obsolescent or discouraged, and legitimately the best tool for the job, is fair game.
nwmcsween 10y ago
You have to be clever sometimes, take strlen in C you could do byte at a time which a compiler will vectorize or you could do SWAR with some fancy bit hacks and get a large perf boost.
- nameless912 10y ago
  A better statement might be: "Don't be clever, let others be clever for you." Obviously, stdlib functions are going to be highly optimized and the compiler will put hardware-specific performance hacks in for your benefit. Smarter people than you wrote, vetted, and approved that code. Use it, and don't ever try to be that smart yourself.
eyelidlessness 10y ago
> Keep your functions to one or two pages. When I encounter functions that large, where the body isn't almost entirely declarative, they tend to be doing way too much. A function longer than 10 lines is a smell, IMO.
bbcbasic 10y ago
I love Haskell but I feel it attracts the most golfy code. E.g. Yes you apply the dot operator to itself but why would you?
- codygman 10y ago
  > I love Haskell but I feel it attracts the most golfy code. I don't feel like most Haskell code is like that and I've read a fair amount. > E.g. Yes you apply the dot operator to itself but why would you? I write a fair amount of Haskell and I despise seeing code that applies the dot operator to itself. Another lambda rather than a double compose is almost always the answer.
  - bbcbasic 10y ago
    > Another lambda rather than a double compose is almost always the answer. Exactly. I also like to choose between do, >>= and <$>, <*> etc. based on readability. I prefer a slightly more clumsy but readable do {...} in many situations.

by hvs 10y ago

0xfaded 10y ago

Caveat, don't be afraid to use advanced language features if doing so eliminates boilerplate.

fhood 10y ago
Caveat Ruby's advances features seem to be designed to make code less readable sometimes.
- 0xfaded 10y ago
  Changing the interpreter's behavior is equivalent to creating a new language. The problem with Ruby (and especially rails) programs is that every program is written in a different language, and what that language is is largely defined by external imports. I have no idea how people have the mental capacity to deal with this.

ScaryRacoon 10y ago

Readable code > cleaver code

tzs 10y ago

> Don't get cute. Code golf is for competitions, not production code. Even if something takes 10 lines that you can do in 1, if 10 lines is clearer, do it that way (you'll thank yourself in 6 months when you have to figure out what you were doing). Brian Kernighan put it well: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

B1FF_PSUVM 10y ago
The other bit I know, besides this one, is to write comments stating what you're trying to achieve, and why. The how is redundant, but sample data right there may help. (Someone famously pleaded for documenting the data structures, and leaving aside the processing mechanics.)

heurist 10y ago

Clever is the enemy! Simplicity is key.

bordercases 10y ago

> Don't get cute I struggle with this. I don't necessarily write a lot of one-liners, but recently I solved a document parsing problem using regex, list comprehensions, zips, etc; generally what are considered "clever" language features to my peers. The problem-solving approach seemed straightforward enough: match labels, slice document, destruct into keys and values into separate list, transform into proper formats and eliminate errors, combine into list of tuples. I could repeat this pattern because the document was structured hierarchically. On one hand, I believe that by using these methods I've written code that is maintainable and less sloppy, and reflects the strongest understanding of the problem. I personally find these language features empowering when I solve the problem. On the other hand, because these features are not the simplest features, the learning curve for interpreting the code is higher. I didn't use any obfuscation methods to compress the code, but neither did I apologize for the usage of the above. What I wonder is: if we don't try to leverage higher-level language features, do we end up defaulting to a brute-force approach with is less contained and raise technical debt? You could hedge around this through liberal commenting, but I find it difficult to believe that avoiding thinking about the problem as being too "clever" is much better. Somewhere there must be a compromise.

pklausler 10y ago
Rule of thumb: Any language feature or library API that is clearly and unambiguously documented, not obsolescent or discouraged, and legitimately the best tool for the job, is fair game.

nwmcsween 10y ago

You have to be clever sometimes, take strlen in C you could do byte at a time which a compiler will vectorize or you could do SWAR with some fancy bit hacks and get a large perf boost.

nameless912 10y ago
A better statement might be: "Don't be clever, let others be clever for you." Obviously, stdlib functions are going to be highly optimized and the compiler will put hardware-specific performance hacks in for your benefit. Smarter people than you wrote, vetted, and approved that code. Use it, and don't ever try to be that smart yourself.

eyelidlessness 10y ago

> Keep your functions to one or two pages. When I encounter functions that large, where the body isn't almost entirely declarative, they tend to be doing way too much. A function longer than 10 lines is a smell, IMO.

bbcbasic 10y ago

I love Haskell but I feel it attracts the most golfy code. E.g. Yes you apply the dot operator to itself but why would you?

codygman 10y ago
> I love Haskell but I feel it attracts the most golfy code. I don't feel like most Haskell code is like that and I've read a fair amount. > E.g. Yes you apply the dot operator to itself but why would you? I write a fair amount of Haskell and I despise seeing code that applies the dot operator to itself. Another lambda rather than a double compose is almost always the answer.
- bbcbasic 10y ago
  > Another lambda rather than a double compose is almost always the answer. Exactly. I also like to choose between do, >>= and <$>, <*> etc. based on readability. I prefer a slightly more clumsy but readable do {...} in many situations.