21–30 of 63 posts
Whenever this kind of disagreement happens with my team, we put it to a vote and then the winning convention is enforced across the codebase from then on. There are tons of things in programming that come down to opinion but the important thing for me is that the team has a set convention and sticks to it.
I have yet to figure out what makes code readable. My own anecdote: I remember reading some code written by Jeff Dean and was amazed by how easy it was to parse and understand. Funny thing is it had quite a few violations of the style guide. In contrast, when I read some of my own code a year later I was scratching my head. It was too dense, variables had too-long names etc. (and it’s the etc that I cannot fully arti…
Lower is better.
OT question from non-native speaker: those commas that mimics speech pauses are syntactically acceptable in English? (Or Greek?) > In Greece, we have a similar phrase [...] > Readable code, is a piece of code [...] > In Germany, they say [...]. > In 16th century, in the Habsburgermonarchy [...] > [...] but let me, tell you a secret: [...] > Readable code, is a piece of code [...] (I'm from Bohemian village where we w…
They should not appear between subject and verb (“Readable code, is...” or “let me, tell...”).
It’s been a long time since I got this stuff in school, so there’s probably a lot of subtleties I’m forgetting.
OT question from non-native speaker: those commas that mimics speech pauses are syntactically acceptable in English? (Or Greek?) > In Greece, we have a similar phrase [...] > Readable code, is a piece of code [...] > In Germany, they say [...]. > In 16th century, in the Habsburgermonarchy [...] > [...] but let me, tell you a secret: [...] > Readable code, is a piece of code [...] (I'm from Bohemian village where we w…
There might be some technicality/formality that insists otherwise but this is so natural a writing style, and so invisible as a result, I had to reread the examples a few times before I understood what you were asking about (thought initially you might be asking about the ... notation which is a bit more idiosyncratic and up for debate as to how to use correctly)
>Next time we have a conflict with a colleague on what is “readable”, let’s ask ourselves “Am I talking about understandability or I am talking about aesthetics?” This is why I'm in favor of auto-formatters like Black for Python. Nobody really likes it, but nobody really hates it either and you get used to it. What this does is that it completely removes the style component of the discussion, leading to better and mo…
I have yet to figure out what makes code readable. My own anecdote: I remember reading some code written by Jeff Dean and was amazed by how easy it was to parse and understand. Funny thing is it had quite a few violations of the style guide. In contrast, when I read some of my own code a year later I was scratching my head. It was too dense, variables had too-long names etc. (and it’s the etc that I cannot fully arti…
It's probably like prose: sorry to write such a long letter, I didn't have time to write a short one. To express something well, you need a sense for all the different ways to express it, to be able to choose the right one. But to just express it, you only need one. anecdote: naming is hard. I can code something in a few hours, and still not have ideal names after weeks. Some come the next day.
Whenever this kind of disagreement happens with my team, we put it to a vote and then the winning convention is enforced across the codebase from then on. There are tons of things in programming that come down to opinion but the important thing for me is that the team has a set convention and sticks to it.
I worked in a place where my team lead wanted us to vote on a technical decision. I found that unfair because half of the team was at a junior level.
We really should stop formatting the actual code to make it 'readable'. The editor or IDE should take care of formatting the displayed code to our preferences with a built in linter/prettier. That should end the pointless and annoying discussion.
I read your comment too fast and I almost dismissed it, thinking you were talking, like everyone else, about formatters (gofmt, rustfmt). But what you are saying is much more interesting, as we are all allowed to keep our preferences. Is there any major editor/IDE working on this? You are making me miserable, now that I read this I can't live with just formatters anymore :D
We really should stop formatting the actual code to make it 'readable'. The editor or IDE should take care of formatting the displayed code to our preferences with a built in linter/prettier. That should end the pointless and annoying discussion.
QBASIC got that right decades ago :-P
QBASIC mostly removed line numbers.
We really should stop formatting the actual code to make it 'readable'. The editor or IDE should take care of formatting the displayed code to our preferences with a built in linter/prettier. That should end the pointless and annoying discussion.
I read your comment too fast and I almost dismissed it, thinking you were talking, like everyone else, about formatters (gofmt, rustfmt). But what you are saying is much more interesting, as we are all allowed to keep our preferences. Is there any major editor/IDE working on this? You are making me miserable, now that I read this I can't live with just formatters anymore :D
You could even sort of brute force this without IDE support by reformatting everything to your preference on git pull and back to ground truth on git stage/push, but when it comes to diffs, merges, etc, you must work in terms of the ground truth formatting. That's not even to mention doing stuff like PR reviews in online tools, not in your local editor/IDE. Going back and forth between the two like this would probably just be counter productive, you're better off just thinking in terms of the ground truth formatting from the start, I'd say.
I think while it might be possible under a very narrow set of limitations and usecases, it's probably just a very leaky abstraction to try to 'hide' the actual formatting of code in a text file.