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

My favorite principle for code quality

pathsensitive.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: My favorite principle for code quality

#51

Post by gowld »

joslin01 wrote: post #9

I feel like this is a long-winded way of saying what Linus already has famously said: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." The author refactors some code to revolve around a "DashboardStat" and explains it came from "thinking about how the code is derived from the design." Personally, I think it came from putting the data & its structure first.

https://softwareengineering.stackexchange.com/questions/1631...

gives some of the genealogy of the idea.

http://www.faqs.org/docs/artu/

"Rule of Representation: Fold knowledge into data so program logic can be stupid and robust."

https://users.ece.utexas.edu/~adnan/pike.html

"Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."

Re: My favorite principle for code quality

#52

Post by amelius »

wvenable wrote: post #47
vorpalhex wrote: post #16

> 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 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.

Re: My favorite principle for code quality

#53

Post by sbov »

> “There’s a bug over there because you re-used lastCachedTime. Otherwise, looks good. Ship it!”

The fixed code still has a bug. It assumes successive calls to lastMidnight() within the method will always return the same date. But presumably, if partway through the method it ticks over to midnight, that would not be the case. So some stats would be updated during one call, and the rest would be updated during the next call.

That would violate this requirement:

> They had previously decided all stats should refresh simultaneously;

Re: My favorite principle for code quality

#55

Post by ljm »

sharpercoder wrote: post #19
vorpalhex wrote: post #16

> 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…

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 which was split between constructors and YAML files) that just called the method of the next dependent class. One line of concrete business logic hidden between half a dozen files full of architecture.

The rationale was that the abstraction was necessary to make things easier to replace if they weren't needed but it was a false assertion on two levels (and it almost always is):

- that kind of replacement is unlikely to happen in the short/mid-term, and if it does it won't be in a way you anticipated.

- the simple version could be deleted and rewritten in less time than it would take to fix your highly abstracted/decoupled/meticulously architected integration

Of course, simple isn't easy and this approach to abstraction (where you take classes/methods longer than x lines and extract them into more classes and methods) is very easy to achieve... at a great cost.

Re: My favorite principle for code quality

#56

Post by crdoconnor »

codemac wrote: post #18
everdev wrote: post #5

> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs. I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requiremen…

Cleanroom has a lot of evidence that process (especially around code inspection/review) does improve quality more than TDD or other methods of detailed design, most people are just unwilling to take the time for detailed process for quality IMO.

That's frequently a reasonable trade off. A lot of businesses need a proof of concept to test product market fit. IMHO TDD can often be a massive waste of time if that is the case.

There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch.

Re: My favorite principle for code quality

#57

Post by SilasX »

aero142 wrote: post #26
sp332 wrote: post #2

Robert Piersig illustrates these higher-level concepts, which he calls forms, Pretty sure that's attributed to Plato. Well I guess he called them είδε but he couldn't wait around for English to get invented.

I think that was one of the great things about Zen. It was an unreliable narrator who had megalomania. At one point, he acknowledges that most of what he is stating is pulled from older greek philosophy that he didn't bother to learn properly but then continues to claim to invent new philosophy through the story.

I get the feeling that most fans of Zen didn't interpret the narrator as unreliable :-/

Re: My favorite principle for code quality

#58

Post by perpetualcrayon »

I find it extremely disconcerting that so many software engineers don't follow this. You're not there to figure out some clever way to do something that you made up. You're first and foremost there to figure out the essence of the thing itself and to find where the design exists naturally. Only then can you really start to design things well IMO.

Re: My favorite principle for code quality

#59

Post by codemac »

crdoconnor wrote: post #56
codemac wrote: post #18

Earlier quoted context omitted.

Cleanroom has a lot of evidence that process (especially around code inspection/review) does improve quality more than TDD or other methods of detailed design, most people are just unwilling to take the time for detailed process for quality IMO.

That's frequently a reasonable trade off. A lot of businesses need a proof of concept to test product market fit. IMHO TDD can often be a massive waste of time if that is the case. There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch.

> There's weirdly not a lot of good advice out there on sensible steps to reasonably transform a rushed proof of concept in to a production quality app. Mostly it all starts with the assumption that you're building something from scratch.

Cleanroom is actually completely reasonable for this - what you must accept is that transforming a rushed proof concept into a production quality application is starting from scratch in terms of ascii in github. It's the experience of those that worked on it that is valuable to save.

Re: My favorite principle for code quality

#60

Post by [deleted] »

krona wrote: post #8
everdev wrote: post #5

> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs. I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requiremen…

Yes, you can't prove a negative. I'm pretty sure it was a joke.

[deleted]
Post reply on HN