51–60 of 335 posts
> To be clear, I don’t mean to dismiss the work of a lone programmer toiling on programs without anyone to pair with or learn from. I’ve been that person many times in my career as a programmer, it’s not fun. I'd say it's a lot of fun.
It completely depends on the quality of your collaborators. Are they good developers, do they have somewhat compatible views, and are they reasonably friendly? I prefer working in a highly capable group.
Mant things are left on the table. First of all, the audience. If you're explaining something to someone, you must consider the audience to be successful. So are we writing code to be read by Go experts? Go noobs? Software Engineers with general background in many lanaguages, but perhaps not go? Noob programmers? You want to assume the lowest level of understanding that is imaginable, and that's probably the last but one I listed in corporate environment.
Now that you have your audience, you gotta wrestle with some high level issues that then trickle down to concrete code. Explicit over implicit. Purity over mutable state. Small code units over monolithic code units. DRY. Verbose naming (that doesn't violate DRY). You gotta agree on the right level of code documentation - especially important for anything that resembles library code (or is an "abstraction").
The hard parts (like good naming) are not Lintable (of course Lint anything you can, use auto-formatter etc.), they are cultured through countless interactions between people in your organization. Getting third opinions is a valuable method here.
It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
This depends on the right-to-left associativity of the ternary operator, so this definitely counts as 'clever'.
It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
The multi-line comparators are definitely clearer and more readable to me. The 10(!) lines of code you referenced are actually only 8(!) lines compared to your 1(!) line because you included the function declaration and the final brace in your count. The line you proposed is 34(!!) characters wide. I wonder if your statement will continue to grow past 80(!!!) characters as your operand expressions grow in width? Will…
return
(a b) ? 1 : // a greater
0; // equalEarlier quoted context omitted.
The multi-line comparators are definitely clearer and more readable to me. The 10(!) lines of code you referenced are actually only 8(!) lines compared to your 1(!) line because you included the function declaration and the final brace in your count. The line you proposed is 34(!!) characters wide. I wonder if your statement will continue to grow past 80(!!!) characters as your operand expressions grow in width? Will…
Maybe you'll prefer return (a b) ? 1 : // a greater 0; // equal
It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
Meanwhile I'll write (a>b)-(a<b), which is what Python suggests after having removed cmp
cmp() is deprecated because there is seldom reason to use it anymore.
E.G:
Sorting words according to their number of letter is just:
sorted(words, key=len)
If you want to rank participants of a game in a dictionary of scores using names as keys and points as values, you would to:
sorted(scores.items(), key=lambda score: score[1])
It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
Fully agree! Combinations of if/else can seriously damage readability and maintainability. I (all the time) face verbose code that pretend to be readable and that requires lots of attention just to find out you are setting a single variable across 10-20 lines. Example: if (cond1) { myVar = 1; } else if (cond2) { if (cond3) { myVar = 10; } else { myVar = 100; } ... } else { myVar = defaultValue; } * huge number of lin…
It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…
YES!! And what do you think the statement
return a b ? 1 : 0;
And that's the point here. In some sense, you are writing to the lowest common denominator. You're a clever guy who can optimize their code to minimize line count and terse statements are obvious to you, but your code will be touched and looked at by developers of all levels. Developers that will have to fix your bugs, and extend your code, or refactor it - years after you write it.
The standard for collaborative programming is to write code to be understood, not to show how clever you are, or to minimize character count or to minimize line count.
Earlier quoted context omitted.
The multi-line comparators are definitely clearer and more readable to me. The 10(!) lines of code you referenced are actually only 8(!) lines compared to your 1(!) line because you included the function declaration and the final brace in your count. The line you proposed is 34(!!) characters wide. I wonder if your statement will continue to grow past 80(!!!) characters as your operand expressions grow in width? Will…
Maybe you'll prefer return (a b) ? 1 : // a greater 0; // equal