Hacker News Reader

Comment by makecheck | Hacker News Reader

On the topic of reading code “written by brilliant engineers”…

Code bases can be so large that you might find brilliantly-written things intermixed with things that are not brilliant (and some of those parts may even have been added by the brilliant engineer on an off day). Therefore, it’s risky to just absorb an entire blob as Good without also understanding its history.

An interesting side effect of languages/ecosystems with single coding styles enforced: bad changes to good code no longer stick out like a sore thumb! In my experience, developers with the discipline to write great code also typically write it in a consistently structured way, and it’s kind of useful that “warts” added by others over time usually won’t follow the structure/style and those warts will be easier to find and scrutinize.

View on HN

Somewhat unrelated, it would be great to have a Medium-style highlight feature for codebases, where you could onboard developers toward excellent practice by highlighting good code in a repository that consists of various levels of code.

That's actually a really brilliant idea.

We have people sometimes produce the software equivalent of a Picasso, but it so rarely comes to light, and even more rarely codified to guidelines/standard-practice.

Would be very good to have "greatest-hits" of a company's codebase, that could serve as internal knowledge-sharing.

Like this?

https://github.com/github/hub/blob/master/github/crash_repor...

Or do you mean with comments in the margin?

> coding styles enforced: bad changes to good code no longer stick out like a sore thumb!

I can see the benefit of being able to identify smelly code immediately from poor code structure. However, I think that coding styles enforce consistency between good programmers who maintain their own coding style. A reviewer should be able to discern code quality - even with compliant code style - by how quickly it is to comprehend.

People often don't realise the person who improved the codebase within a short span of time had years of experience in the domain. I know a class of engineers who are solving the EXACT same problem using the EXACT same method from from company to company. To someone from outside, it might appear like they are job hopping looking at their average time spent at a company.

The effect can't last long though: The long-surviving codebase becomes such a mix of styles that it's more noise than signal, and even the good code appears as just another local inconsistency.

Reply on news.ycombinator.com