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

71–80 of 115 posts

Re: My favorite principle for code quality

#71

Post by amelius »

dagss wrote: post #62
amelius wrote: 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...

This assumes that if you rewrite a piece of code then the possible bugs in the new code are similar to the bugs in the old code. And that is in general not true.

Re: My favorite principle for code quality

#72

Post by flukus »

icedchai wrote: post #10
trhway wrote: post #4

seems the article ends up with what was first done decades ago in PHP - separation of presentation and business logic. Btw i don't understand all this animosity toward PHP, especially given that pretty much all the modern web development is basically PHP-like, in spirit if not in actual implementation.

Most PHP is actually the opposite... Many PHP scripts, especially those from decades ago, are a mix of HTML, database calls, and business logic all in the same file.

And now we have JSX and this is considered good again.

Re: My favorite principle for code quality

#74

Post by james_marks »

madeofpalk wrote: post #68
michaelcampbell wrote: post #42

Earlier quoted context omitted.

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

Because DRY as an end-goal can become over-abstracted and taken too far, we came up with WET as the counterpart: Whatever is Efficient and Transparent. In the end, we found you want to be somewhere in between.

Re: My favorite principle for code quality

#75

Post by roenxi »

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…

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 HN a while ago [1] illustrating how blindly guessing an OOP hierarchy for a problem isn't going to help. Throw that at a learner without thinking too hard, and they are going to question what the benefits of OOP even are - it doesn't always simplify a problem.

[1] https://www.quora.com/Is-abstraction-overrated-in-programmin...

Re: My favorite principle for code quality

#76

Post by justicezyx »

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…

When I read the article, I was confused about the end result, as I am fully aware of the legacy garbage from overly abstracted code base, and I was very surprised this guy seems fully confident about its approach...

Re: My favorite principle for code quality

#77

Post by justicezyx »

oldgeezr wrote: post #29
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…

+1 From the author's page: > I work at MIT trying to make program transformation and synthesis tools easier to build So, the author works in an academic environment. He doesn't have to deal with real-world code, budgets, bugs, teammates, etc. Please take his coding advice with a grain of salt.

> Please take his coding advice with a grain of salt.

I think engineering advices from non-engineers should just be discarded...

Re: My favorite principle for code quality

#78

Post by andreareina »

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…

HN thread: https://news.ycombinator.com/item?id=16047497

Re: My favorite principle for code quality

#79

Post by repsilat »

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…

Mm. For me there are only a few reasons to use inheritance:

- Common operations between classes, operating on common data, but requiring an external API (so composition is a pain because you would have to proxy those actions to the member.)

- Restricting/specifying the types of objects you can store in a container if you are programming in a language/codebase that cares about that (incl. the C++ "definitely has the vtable I want".)

And maybe that's it? I guess all the taxonomy talk might be useful in the first hour of learning about inheritance, but after that I think the analogy should give way to more concrete "what are the code and data doing?" angle.

Re: My favorite principle for code quality

#80

Post by vorpalhex »

wolco wrote: post #44
some_account wrote: post #36

Earlier quoted context omitted.

I agree. Developers should never build anything more complicated than it has to be at the moment. Simplicity is key to happiness and productivity.

We shouldn't go too far with this line of thinking either. When things are immutable design early. Consider an api. You can build a basic api without a version parameter when you release. When you need to change the api and keep backwards compability you introduce a version parameter. You are forever stuck with the first version being the default.

Versions, timestamps and unique IDs are definitely base design requirements on anything.
Post reply on HN