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

91–100 of 115 posts

Re: My favorite principle for code quality

#91

Post by fenomas »

roenxi wrote: post #75
mikestew wrote: post #43

Earlier quoted context omitted.

How about: if you're peddling software design advice, take some time to make (or find) a realistic example so I don't have to imagine so hard. Somewhere around 1989 I swore that the next author of an OOP book that used animals as class examples was going to get an angry personal visit from me. "Suppose you have an Animal class. We subclass to a Cat, and add a Meow method..." If it wasn't animals, it was cars: "we'll…

I'm no expert at OOP, but never have I seen a student who telegraphs a look of comprehension after seeing an example of classes involving animals. I've seen many who get more confused. Classes are a neat way of hiding implementation detail behind a mini-api that has reasonable code-hygiene benefits and works well in a team setting. None of these things have anything in common with meowing cats. There was a classic on…

> never have I seen a student who telegraphs a look of comprehension after seeing an example of classes involving animals

I think it's a classic case of teaching people the answer before the question.

Animal examples explain what types and subtypes are, but the thing that warrants explaining is why and when it's useful to separate things into types and subtypes, and animal examples are terrible for that. If someone asks "should Cat and Dog inherit from Quadruped? Mammal? Pet?" there's no useful answer.

Re: My favorite principle for code quality

#92

Post by stankypickle »

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…

Fully agree. KISS

Re: My favorite principle for code quality

#93

Post by spc476 »

mikestew wrote: post #43
Jach wrote: post #38

Earlier quoted context omitted.

Fully agree, let's not go back to instinctively applying all of the patterns from GoF. I'd also like to quibble with just this: > When reading software design advice, always imagine the examples given are 10x longer. How about: if you're peddling software design advice, take some time to make (or find) a realistic example so I don't have to imagine so hard. Even if it's in a toy-problem type of scenario the code can…

How about: if you're peddling software design advice, take some time to make (or find) a realistic example so I don't have to imagine so hard. Somewhere around 1989 I swore that the next author of an OOP book that used animals as class examples was going to get an angry personal visit from me. "Suppose you have an Animal class. We subclass to a Cat, and add a Meow method..." If it wasn't animals, it was cars: "we'll…

Once I learned about Unix, I felt that IO devices would make a better example of class inheritance. You have a base abstract class. From that, you get a block device (seekable devices with fixed-sized blocks), a character device (say, a serial port, or a keyboard), a variableblock device (like a tape drive or network, with variable sized blocks that may or may not be seekable). And then you can subclass from there. A more or less realistic example.

Re: My favorite principle for code quality

#94

Post by sooheon »

mikekchar wrote: post #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.…

I like the way you think, do you write anywhere else?

I'm only in my first year of designing and writing code professionally, much of what you point out about this being 1. difficult, and 2. a social/human endeavor rings true.

Re: My favorite principle for code quality

#95

Post by mark_edward »

zackbloom wrote: post #49
jpochtar wrote: post #23

I believe the code presented would have benefited from a lambda-based API approach instead of an object-oriented one. In Javascript: // global, since the cached values were apparently global in the original let cache = {}; let lastCachedTime = 0; // Utility for fetching potentially cached values, or computing them // if there's no valid cache entry. let cached = (id, recompute) => { // I don't love this policy, but t…

Yes, 90% of abstraction is best done by organizing files and functions, NOT by creating classes.

Unfortunately these are largely the same thing if you're stuck with Java <= 8

Re: My favorite principle for code quality

#98

Post by dagss »

wvenable wrote: post #70
dagss wrote: post #62

Earlier quoted context omitted.

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…

Sounds like you are writing tests at the wrong level then.

I was talking about a regression test for a fix for a bug found in production. For a typical backend, write such tests against the publicly exposed API.

If you end up breaking tests as you refactor it means that you have broken backwards compatability for others who use the API...

Re: My favorite principle for code quality

#99

Post by m12k »

antirez wrote: 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 agree, generalize too early, and you are just as likely to overengineer, anticipate changes that never come (YAGNI), constrain the code in other ways that turn out to be unwieldy and incur the mental overhead of a more complex design that each new reader of the code needs to understand. Generalization should mostly happen during refactoring.

Re: My favorite principle for code quality

#100

Post by lnanek2 »

sbov wrote: post #53

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

He does point out every good programer knows they should have one if check for all three: " Wrapping Up . Many programmers will get a sense that something was off about the first example. Every programmer I’ve shown this example to knew they should merge the if-statements and factor out the prints. "

Which corresponds to the one if part of the story: " if (lastCachedTime So having the multiple ifs being bad even before a second cache refresh is added is part of the story.

Post reply on HN