4 ms·

How much you suck as an engineer = 1/(sum(len(n) for n in Nv)/len(Nv))

10 points by oneelectron 6y ago

This is conjecture that programmers should aspire to write self-documenting and expressive code. Terse code is just poor form, in the modern programming world. Xc = ds.imgtf(tsf, sz, rm, sc) vs // normalize the input images processedInput = inputData.processImages(customTransform, finalSize, resizeMethod, maximumScaleFactor) Sample1 is preferred by most people I work with, and the standard for almost anything you'll find published in Python or Java. The web world is a little more forward on this, although still behind if you ask me. I have always followed a practice of writing goals as comments first, then comments as pseudocode, and then simply adding in the syntax below that, with variable names that would be obvious at a glance. However, colleagues have found this practice "Nazi-like" and some have even made hard stances against putting comments in production code, at all. It's almost a side job for my colleagues to show me that my concerns are unwarranted. Is it acceptable to demand rigor in expressive naming conventions and heavy commenting within my team? I'm seeking opinions on a team guideline for erring far on the side of readability over conciseness. I argue it has tangible benefits, and would've mitigated problems we've already stumbled on. (edit: I removed a bunch of ranty prose like "What year is it")

tlack 6y ago
Strongly disagree but upvoted for the conviction of your delivery. :) Writing robust programs relies on unquestionable understanding of the logic. The specific variable and argument names are neither here nor there. It's almost impossible to understand program flow when code is extremely verbose and heavily abstracted. Little comments like "add 1 to x!!" are not only useless in practice but they are toxic to code understanding. The code already tells you what it does. As a maintainer, I need to understand why, and to what ultimate purpose. "tmp2 -> temporaryFailedCustomerRecordsCounter" wastes precious space making the obvious infantalizing. It's ok to expect people working on your complex, important software to be knowledgeable about the domain and its' standard terminology. I expect my Lyft driver to have a drivers license.
- oneelectron 6y ago
  Glad you can defend the totally opposing view well. Respect on the 'knowledgable about the domain' point. I would argue that there is no more abundant resource than whitespace on computers. Useless comments (usually written after the syntax is written) definitely suck. But in a file with well written comments, you can actually just read the comments alone and understand the code as fast as you could read news headlines. Another point, the only purpose of code as we know it is to serve as a human-readable translation of machine instruction. To me, the best achievement of that is a document that reads like natural language. After all, wouldn't it be better if we could just describe intentions in common speak and have the computer figure out the details? To me, well thought verbosity in code is a step towards that.
  - gundmc 6y ago
    IMHO, comments should never describe what the code does. We're engineers, we can all read code and see what it does (or refer to the Javadoc). Comments should be used to describe WHY the author is doing something non-obvious in the code.
    - oneelectron 6y ago
      Definitely agree with commenting deviations. Although I also advocate comments for each "operation". No problem if 5 lines of the same operation go uncommented, but if you have 5 lines of map().reduce().filter(), save your friends time and just pop in a // Find the top 3 posts by comment count Suffering comments you already understand > running a VM in your head when you forgot
  - tlack 6y ago
    Good points. Some rebuttals: First, in the context of this argument, I'm talking about work in high level languages like Python, JS, fairly expressive C++, etc. If we were coding in assembler -- LEA, LDR, JNZ.. -- I'd definitely want a ton of low level comments! When I say wasting space, it's not about disk space, or shrinking your screen size, or even formatting. It's more about what you can see all at once. Think back to a recent time when you had a tough to fix bug. Like something really not trivial that you beat yourself up about for a while. I bet it involved you working through various levels of libraries, opening them side by side or paging back and forth, trying to figure out what went wrong in the logic. It probably wasn't cuz you misunderstood what a variable did. We have great ways to document that, like the function header. Now imagine that process if it's all on the same screen. If everything feels "tangible" to you, because each level of logic (to some reasonable point) is visible, accessible. When I encounter a code base with hundreds of source files in various folders and some flimsy abstraction tying it all together, such that I can't see a clear delineation between parts, I go nuts! Here's a very practical example. Imagine you have some library that wraps a remote API. Something important, like Payments. The hard part there is understanding failures (does it retry?), edge cases (whats diff when i run a test CC#?), stored state (can I resume this from a different part of the code?).. those things are mighty hard to glean even from good statement-level comments, even if I could take the time to read all 3,000 lines of code. We need higher level great docs. I'd love to code in English or something like it, but looking at the code on my screen right now, those would be some really complex sentence structures. :)
_drimzy 6y ago
Google gets rid of this problem (either extremes) by formalizing style guides for the different coding languages people use in its organization. Checkout https://google.github.io/styleguide/ https://google.github.io/styleguide/

10 points by oneelectron 6y ago

tlack 6y ago

Strongly disagree but upvoted for the conviction of your delivery. :) Writing robust programs relies on unquestionable understanding of the logic. The specific variable and argument names are neither here nor there. It's almost impossible to understand program flow when code is extremely verbose and heavily abstracted. Little comments like "add 1 to x!!" are not only useless in practice but they are toxic to code understanding. The code already tells you what it does. As a maintainer, I need to understand why, and to what ultimate purpose. "tmp2 -> temporaryFailedCustomerRecordsCounter" wastes precious space making the obvious infantalizing. It's ok to expect people working on your complex, important software to be knowledgeable about the domain and its' standard terminology. I expect my Lyft driver to have a drivers license.

oneelectron 6y ago
Glad you can defend the totally opposing view well. Respect on the 'knowledgable about the domain' point. I would argue that there is no more abundant resource than whitespace on computers. Useless comments (usually written after the syntax is written) definitely suck. But in a file with well written comments, you can actually just read the comments alone and understand the code as fast as you could read news headlines. Another point, the only purpose of code as we know it is to serve as a human-readable translation of machine instruction. To me, the best achievement of that is a document that reads like natural language. After all, wouldn't it be better if we could just describe intentions in common speak and have the computer figure out the details? To me, well thought verbosity in code is a step towards that.
- gundmc 6y ago
  IMHO, comments should never describe what the code does. We're engineers, we can all read code and see what it does (or refer to the Javadoc). Comments should be used to describe WHY the author is doing something non-obvious in the code.
  - oneelectron 6y ago
    Definitely agree with commenting deviations. Although I also advocate comments for each "operation". No problem if 5 lines of the same operation go uncommented, but if you have 5 lines of map().reduce().filter(), save your friends time and just pop in a // Find the top 3 posts by comment count Suffering comments you already understand > running a VM in your head when you forgot
- tlack 6y ago
  Good points. Some rebuttals: First, in the context of this argument, I'm talking about work in high level languages like Python, JS, fairly expressive C++, etc. If we were coding in assembler -- LEA, LDR, JNZ.. -- I'd definitely want a ton of low level comments! When I say wasting space, it's not about disk space, or shrinking your screen size, or even formatting. It's more about what you can see all at once. Think back to a recent time when you had a tough to fix bug. Like something really not trivial that you beat yourself up about for a while. I bet it involved you working through various levels of libraries, opening them side by side or paging back and forth, trying to figure out what went wrong in the logic. It probably wasn't cuz you misunderstood what a variable did. We have great ways to document that, like the function header. Now imagine that process if it's all on the same screen. If everything feels "tangible" to you, because each level of logic (to some reasonable point) is visible, accessible. When I encounter a code base with hundreds of source files in various folders and some flimsy abstraction tying it all together, such that I can't see a clear delineation between parts, I go nuts! Here's a very practical example. Imagine you have some library that wraps a remote API. Something important, like Payments. The hard part there is understanding failures (does it retry?), edge cases (whats diff when i run a test CC#?), stored state (can I resume this from a different part of the code?).. those things are mighty hard to glean even from good statement-level comments, even if I could take the time to read all 3,000 lines of code. We need higher level great docs. I'd love to code in English or something like it, but looking at the code on my screen right now, those would be some really complex sentence structures. :)

_drimzy 6y ago

Google gets rid of this problem (either extremes) by formalizing style guides for the different coding languages people use in its organization. Checkout https://google.github.io/styleguide/ https://google.github.io/styleguide/