Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

Post reply on HN
Print view View original

81–90 of 245 posts

Re: Maintaining code quality when nobody cares

#81

Post by epicide »

tboyd47 wrote: post #56

> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or…

In business settings, I've seen plenty of pull requests "go stale". Usually, they come about from a) the person not updating their code based on reviews, b) the reviewers not reviewing in a timely manner, or c) the change is no longer necessary / a priority.

Usually, it is some combination of a and b. All cases are an indication of a deeper problem. None can be fixed by calling your "pull request" a "managed push" nor by giving people unrestricted access to pushing code. It's typically either a problem with communication or priorities/expectations.

Re: Maintaining code quality when nobody cares

#83

Post by ryanianian »

bunderbunder wrote: post #55
crdoconnor wrote: post #20

Earlier quoted context omitted.

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

I agree, linting doesn't pick up much. But, at places I've worked where the codebase was kept linted, the humans did a better job of catching bugs in code review. My guess is that, when you have a cosmetically messy code base, people start to develop a lower standard for what counts a understanding the code they're reading. Probably as a self-preservation mechanism. There's only so much time in a day.

Also: if your coworkers care enough about quality to add and maintain a linter, they're the kind of coworkers that care to do good code-reviews and maintain a high quality bar.

Re: Maintaining code quality when nobody cares

#84

Post by tootie »

tboyd47 wrote: post #56

> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or…

Tech lead is dictator. You should have a tech lead who is at least 50% hands-on coding and is enforcing the code review system and participating in as many as possible.

Re: Maintaining code quality when nobody cares

#85

Post by jerf »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

"IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor)."

What language are you using? Dynamic languages are fairly difficult to meaningfully lint because it's hard enough just to analyze a function for problems, let alone extend past that. Static languages are easier to write non-trivial linters for, because there's more information just sitting there in the source, waiting for something to grab it.

But even for dynamic languages, linters can still do things like enforce documentation standards, code testing/coverage standards, and some other basics that may sound trivial, but still add up to very useful things.

Re: Maintaining code quality when nobody cares

#86

Post by jacquesm »

eitland wrote: post #71
jimmy1 wrote: post #22

Earlier quoted context omitted.

In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time. Downvotes are usually…

Like it or not but legacy has taken a new meaning in software. I think it is Michael Feathers who defines it as code without tests in "Working Effectively With Legacy Code". (That said, I didn't downvote you and I'm also tired of the abuse of the downvote button. I think in your case they downvoted because it seemed like unproductive nitpicking.)

I like that definition. Maybe another one: code that nobody knows intimately.

Re: Maintaining code quality when nobody cares

#87

Post by crdoconnor »

lloeki wrote: post #28
crdoconnor wrote: post #20

Earlier quoted context omitted.

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier…

IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves".

  lint [cosmetic | medium | serious]
- you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you might plausibly say "I'm not unhappy that broke the build because it could have indicated a bug".

  lint medium --against=branch
- the linting tool should be able to intelligently compare against a baseline branch and only warn you about issues on code you have actually touched.

I do not agree that the holistic effect of having a code base "normalized" is "through the roof". I think the cost is relatively high while the benefits are relatively low. Right now at work if I run a linter against my code there are about 10,000 "issues" - the top 50 of which are completely cosmetic and I'd be remiss to invest time in fixing them.

I'm not opposed to linters on principle and I do use them, I just think that there's almost always bigger fish to fry.

Re: Maintaining code quality when nobody cares

#88

Post by danharaj »

aalleavitch wrote: post #74
Kesty wrote: post #69

Earlier quoted context omitted.

And unfortunately nothing will change because what you want to do is better in every single way, but their way of doing thing is better in the only one that actually counts: It's faster and cheaper.

My assumption is that I will never clean up this entire codebase. Rather, I’m looking for the best way to triage the situation: what are the things I can/should try to fix first?

Write down everything you know about the codebase. Whenever you discover a surprising dependency or behavior make a note of it. This is something you can do in passing as you push features.

At some point you'll start recognizing structures in the code some of which will be small enough to surgically improve.

Re: Maintaining code quality when nobody cares

#89

Post by gboudrias »

hawski wrote: post #79
tboyd47 wrote: post #56

> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or…

What I don't like in "commercial" code reviews is that most reported issues are there just to fill space. It's busy work. There is this formal comment system. So instead of fixing this typo in a code comment directly reviewer writes a comment. Code style issues that arise, because of absence of a tool like go-fmt also warrant a comment. That's sad. There are meaningful comments, but usually people have to fill their…

Good comment. The thing to remove in the story is a duck: https://en.wikipedia.org/wiki/Law_of_triviality#Related_prin...

Re: Maintaining code quality when nobody cares

#90

Post by justherefortart »

troels wrote: post #54
justherefortart wrote: post #53

Earlier quoted context omitted.

Apparently. I just started laughing when I heard about it. I'm going to pitch an ASP (classic) project next!

I don't know if you're joking or not about the ASP classic.

I'm joking. I would not start a new project in Classic ASP in 2003, much less 2018.

I did like it back in the day though and it was still a better choice than .Net 1.0. .Net 1.1 was okay, by 2.0 it was pretty decent. 4.0 beyond is fantastic IMO. I'm a bit of an MS fan though. I like their tools.

Post reply on HN