Live data from Hacker News

My favorite principle for code quality

pathsensitive.com

61–70 of 115 posts

Re: My favorite principle for code quality

#61
post #55

Earlier quoted context omitted.

This boils down to code removeability . A few larger classes wit large methods is in general easier to remove/refactor then a large amount of small cohesive classes with an obtuse design concept behind it. Of all the codebases I refactored, I take the "large methods and large classes" hands down. Pulling a few classes here and there is easy, compared to first understanding a clusterf*ck of overengineered abstractions…

I worked with a domain driven setup at one point, which seemed like it was designed to sell JetBrains licenses because it became almost unbearable to try and maintain the codebase with a text editor. You would have to go through a controller, a DI container, a repository, an entity, a factory, a builder, maybe a facade, and an event bus... almost all of which were single-method classes (except for the DI boilerplate…

This makes me think of a good thinking talk, with a quote I pull out from time to time:

> I hate code, and I want as little of it as possible in our product.

http://pyvideo.org/pycon-us-2012/stop-writing-classes.html

Re: My favorite principle for code quality

#62
post #52

Earlier quoted context omitted.

This is great advice but the real problem is that so many developers never go back and change their code. They are always moving forward and never revisit their old solutions. I constantly re-writing and re-organization code as the problem changes but I feel like that's the exception rather than the norm. We need to teach that change is good and a normal part of the process.

The problem is of course that you may then be changing code which has been field-tested for a long time.

As long as the process had been that the only way to get a pull request for a bugfix accepted is by proving the bugfix worked with an automated regression test, then you can change the code as much as you want...

Re: My favorite principle for code quality

#63

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

This boils down to code removeability . A few larger classes wit large methods is in general easier to remove/refactor then a large amount of small cohesive classes with an obtuse design concept behind it. Of all the codebases I refactored, I take the "large methods and large classes" hands down. Pulling a few classes here and there is easy, compared to first understanding a clusterf*ck of overengineered abstractions…

As long as we acknowledge that large classes with large methods can also cause problems. Dealt with that before and it is not fun by any means. The worst offenders, though, are the projects that have a LOT of large classes with large methods, plus some crazy abstraction thrown in like a dash of pepper.

Re: My favorite principle for code quality

#64
My advice for design: Design is hard. Good design is so hard that you will almost never see it in the wild. It becomes even harder when you work with other people. Your carefully crafted ideas will be crushed under the foot of the next confident programmer who thinks they have found the holy grail of design. As more and more programmers are added, they pour in their particular favourite flavour of programming sauce. The result is swamp water.

Good design is not about the code. Good design is about the people who are going to work with that code. Understand your audience. Get to know what they like and what they don't like. Write your code in a way that will delight your audience. Give them what they expect to see.

Of course, this is exceptionally shallow advice because no programmer can actually be so selfless. If you write code that pleases your audience you will usually have to do so at the expense of yourself. It is not possible to write good code that you dislike -- at least not long term.

So the trick to good design is always putting a bit of yourself in the code and always putting a bit of your colleagues in the code. It's striking that balance where you are satisfied, but also where they are satisfied. This requires working in small increments, and sharing what you are doing. It requires watching what your colleagues are doing and looking for opportunities to borrow. It requires questioning, evaluating, praising, explaining and coaching.

And if you are working by yourself: do whatever the hell you want. Why are you so worried about what other people think? If you are trying to improve what you are doing, don't do so by reading about the opinions of others. Read code, not blog posts. Write code, not design diagrams. Work slowly, try out ideas you've seen in other code and evaluate their success. When you get the chance, work with others to broaden your horizons.

Re: My favorite principle for code quality

#65
post #55

Earlier quoted context omitted.

This boils down to code removeability . A few larger classes wit large methods is in general easier to remove/refactor then a large amount of small cohesive classes with an obtuse design concept behind it. Of all the codebases I refactored, I take the "large methods and large classes" hands down. Pulling a few classes here and there is easy, compared to first understanding a clusterf*ck of overengineered abstractions…

I worked with a domain driven setup at one point, which seemed like it was designed to sell JetBrains licenses because it became almost unbearable to try and maintain the codebase with a text editor. You would have to go through a controller, a DI container, a repository, an entity, a factory, a builder, maybe a facade, and an event bus... almost all of which were single-method classes (except for the DI boilerplate…

Indeed. I am always surprised/amused by how often someone will go to the ends of the earth to criticise big up-front design and proclaim that you ain't gonna need it, but then routinely set up several layers of indirection and abstractions in the most basic code, frequently for no immediate benefit other than letting their similarly complicated automated test suite run.

Re: My favorite principle for code quality

#67
post #35

I can't disagree more with this post. One should always aim at trivial code, but as things get more complex, it is there the the sensibility should fire in and make you say, ok I need more abstraction now, and refactor accordingly. But even then it is important to just add the minimum amount of abstraction to generalize the problem at hand, without thinking like "but why if in the future we change things..." Unless i…

I find this true, and depressing at the same time. The amount of curation needed for a constantly evolving code base is vastly underestimated by most, even to achieve the modest design goals (IMO) that you are espousing.

Re: My favorite principle for code quality

#68

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

A recent quote by Evan Czaplicki of Elm fame that I've come to like; "Abstraction is a tool, not a design goal."

Comments along this line are my favourite in our industry. Harry Roberts said, back in 2014, "Modularity, DRY, SRP, etc. is never a goal, it’s a trait. [...] but understand that they’re approaches and not achievements". This advice has stuck with me ever since.

https://twitter.com/csswizardry/status/539726989159301121

Re: My favorite principle for code quality

#69
post #31

> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…

I have to agree. There are OTHER errors that can be introduced by having too many wrapper classes/methods. Clutter (code volume) also adds to causes of mistakes. I don't know what particular mistakes could come about in this case, but more code == more errors in general. Wrapping stuff into mini abstractions is not always an improvement. As a rule of thumb, if some code pattern repeats 5 or more times, an abstraction…

> but more code == more errors in general.

you can't have bugs in code you never have to write!

Re: My favorite principle for code quality

#70
post #62
post #52

Earlier quoted context omitted.

The problem is of course that you may then be changing code which has been field-tested for a long time.

As long as the process had been that the only way to get a pull request for a bugfix accepted is by proving the bugfix worked with an automated regression test, then you can change the code as much as you want...

Tests lock you down to particular design by way of the interface. If you want to fundamentally redesign something, you're likely going to have to change the tests as well.

The power of automated testing is really to ensure that nothing changes, which is great when doing bug fixes, but not so great for actually evolving software.

Ultimately it just becomes easier to add new code than it is to ever change a design that is already in place.

Post reply on HN