One can talk about about the technical side of writing a code formatter, but what about the ethical side? Automatically formatted code looks kind of okay but never great. Uniformity for the sake of uniformity. It is not a very humanistic.
There seem to be a lot of posts that attempt to cast seemingly mundane things through an “ethical” lens and I often wonder what the authors of them must be like in real life.
There are 3 major problems with automated code formatters:
* Handling of multiple newlines to break sections, or none to group related functions (e.g. a getter with a setter). Sometimes it's even best to move functions around for better grouping.
* They don't factor out an expression into a separate variable.
* They destroy `git blame`. This one is avoided if the tooling has always enforced formatting.
Regarding the second one, a formatter shouldn’t be changing the AST. At most inserting parentheses/braces/semicolons for clarity, which doesn’t change the AST structurally (or, depending on one‘s definition of “AST”, doesn’t change it at all).
Perhaps, but it is absolutely relevant. Most of the horrible formatting results are due to the formatter trying really hard when the user really should introduce a variable.
True, formatters can only do so much. The purpose formatters is not to guarantee readable code, but to guarantee uniform code. Use of a formatter doesn’t relieve a programmer from taking care that the code is readable. But it ensures that everyone is using the same formatting conventions.
How is this a problem with auto formatters? This is completely on the person/team, not the tool. Even if the repo doesn’t enforce on pre-commit or something, don’t most formatters have the option to only format lines you’ve actually changed?
Interesting comment. I always saw the formatting aspect as the sort of drudgery the computer could do for me. (As a bonus, it will always do it completely consistently.)
yeah, I've come to terms that I mostly do programming-as-an-art and that includes how my code is structured, and I'm on exactly the same page.
In pragmatic business environments it's not worth the fuss but I never feel great about anything I make in those kinds of environments anyways, and I always appreciate being able to shine when there's no enforced code formatting.
"Ethics" is overdramatizing it. The goal of a code formatter is not greatness, but adequacy, in a context where the code is a means to an end. They're particularly used in contexts where you may be sharing the project with people who don't care about formatting at all. Forcing me to work in or clean up the messes of my lazy co-workers is also, I would suggest, not very humanistic.
I agree, actually. Humans are visual creatures and they take cues from the visual design of program code: alignment, grouping, density. All these things are used to signify meaning in product design, including digital design. But we are not allowed to "design" source code.
semantic code style varies plenty between people; i can often tell who wrote which code, among the members of my research group, even though we format our code. i'd prefer to be recognized by my preference for short lambdas (vs. defs) and partial functions, than my preference to put if statements on one line.
The bike shedding is optional once one accepts that code written by someone else might look a bit different from ones own. _Some_ conventions are beneficial, and one might discuss those, but one does not have to have complete uniformity.
Bike shedding for weeks might happen and is not helpful. On the other side of this argument there are not-so-very-pleasant things as well.
A: We follow this-and-this coding convention and we do not like wasting time on discussing it so we follow it to the letter.
B: I don't like this small thing that I would like to write differently.
A: We follow this-and-this coding convention and we do not like wasting time on discussing it so we follow it to the letter.
B: You actually don't follow this-and-this coding convention because you are not following this-and-that rule.
A: Yes, that is a change that I liked.
One can easily end up with a very old coding convention that only the oldest developer likes so the oldest developer can now be dictator over everybody else.
