Hacker News Reader

Comment by paulhodge | Hacker News Reader

this advice isn't all that useful.

On that first one: "Every outperformer I knew had the style guide internalized"

No thanks.. It's the year 2023, just install an autofixing linter which fixes the code for you, and then worry about other things.

View on HN

That’s not the only thing that maintaining consistent style involves. For example, we have an auto linter at my job, but there have been a few (bad) engineers whose code I can recognize even after it’s all auto-formatted.

Plus, when you’ve spent enough time with the code in varied environments, you start to internalize what it should look like. Seeing something that doesn’t match the style guide will stand out as looking funny.

I don’t think they were suggesting that you need to memorize every minute detail of your prettier config to be a good engineer. Rather, a good engineer has focused on writing clean-looking code so intensely for so long, to know it automatically.

Exactly, I’m all for readable code but this style guide stuff is cargo culting. The guides are the culmination of wisdom of past decades where IT became dominated by a few language stacks. Innovation happened elsewhere as computers got faster, bigger and use cases grew but did not transform. This changed and use cases and targeted platforms are different now calling for new stacks with new conventions. A typical developer is exposed to myriad languages and tools. Documenting small details in proper format never was enough but these days it has become ever more important to focus on communicating context and motivation.

That works for new code, but I'm much less keen when maintaining legacy code. Sure, you could reformat every file and then proceed to work on them, but then you've had a serious impact on the version history, worsening tools like git blame and often making it harder to understand how a particular piece of code evolved. It's even worse if one reformats and then makes a code change in the same commit...

fixing whitespace is something to do while thinking about the code. unless you can't do two things at once in which case it's a problem. either way, autoformatting doesn't magically make you engineer faster unless your company enforces a style in a really fascist and pedantic way

Autoformatting makes me faster because I don't have to think about it at all. All of the code in the codebase looks pretty similar and it opens up a sliver more mental RAM

If anything, each chunk of code having its own distinctive structure would make the code easier to visualize. If all the code looks the same then you have no landmarks. Do you not visualize code?

I do visualize it but the logic is the landmarks. It's like living on a grid system such as in Utah or New York but you still know where Times Square is and how Broadway connects everything

You cannot know the logic prior to reading and understanding the code unless you recognize the code immediately on sight. That is my point. If I see a nested ternary expression with beautiful indentation, I know I've scrolled too far when I'm looking for a certain method.

Method names are not logic. You really don't use distinctive method names or formatting to orient yourself and your colleagues? That sounds awful.

I misunderstood what you meant then. Obviously I use descriptive names and different styles of elements inherently have different shapes to them but I don't choose to add extra lines or change spacing just to make something look distinct. As I scroll through I see blocks, names, fors, lambdas, these form the shapes of different bits of code. The baseline formatting of each of these elements is uniform though

Reply on news.ycombinator.com