My favorite principle for code quality • Hacker News Board

Re: My favorite principle for code quality

#81

Post by rifung » Wed, May 23, 2018, 2:22 AM UTC

amelius wrote: post #52

wvenable wrote: post #47

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.

I agree but also think it's worth acknowledging the trade off you're making. If you never touch a piece of code, then at some point nobody remembers or is able to understand what it's doing.

I think this is worse than changing code that has been field tested but admit I am biased because I work on a large project where we are beginning to run into this problem.

Re: My favorite principle for code quality

#82

Post by InclinedPlane » Wed, May 23, 2018, 2:27 AM UTC

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…

To add to this, don't diminish simple and easy abstractions. There's often a tendency in software development to make use of the fanciest, most complicated tool available, rather than the most practical one. It's easy to forget that just wrapping something up in a handful of static functions and a couple data types is still abstraction, and often it's the right level of abstraction.

Design patterns are a great thing to understand but they can be dangerous when used incorrectly. I've had to deal with overly design patterned code and it can be a nightmare. You go searching and searching for the "sharp tip of the spear" where you can actually get something done and then you find out that you need some sort of special object. Then you find out that the object doesn't have a constructor it has to come from a factory method. And you can't just call that factory method with parameters, oh no, you need to pass in some special property bag object, and so on.

Don't worry about trying to show off, worry about making your life easier. The ideal situation is that if you want to do some new thing X that is similar to but slightly different from other stuff your system does then you will not only have a good idea of how to do that with the existing primitives, utility methods, abstractions, etc. but it will also be a fairly straightforward task to add that functionality.

Ask yourself these questions about your code base:

- how easy is it to read the code and figure what it does?

- how easy is it to figure out how to use it?

- how confident can you be that the code is correct just by looking at it?

- how difficult is it to maintain and add new functionality to?

- how easy is it to test?

Let those guide your designs.

Re: My favorite principle for code quality

#83

Post by jstewartmobile » Wed, May 23, 2018, 2:49 AM UTC

yani wrote: post #24

vorpalhex wrote: post #14

Earlier quoted context omitted.

> i don't understand all this animosity toward PHP Most PHP code is terrible . That's not really PHPs fault - it's capable of producing very nice programs with beautiful behavior. As a language, it suffers a bit from being older and it was internally very inconsistent for a long time. For a long while, it's package management and practices were way behind the curve. Many people who program in PHP learned it as a firs…

For what use case is PHP better than other languages?

Rapid development of performant get/post web interfaces. Ruby is nice but runs a lot slower. Python is better in a general-purpose sense, but every file will have a preamble of includes for things that are just built-in to PHP.

As a general purpose language, PHP is weak. As a web-form DSL, it's great!

Re: My favorite principle for code quality

#84

Post by jstewartmobile » Wed, May 23, 2018, 2:53 AM UTC

flukus wrote: post #72

icedchai wrote: post #10

Earlier quoted context omitted.

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.

Jumble code and markup together in PHP, and you've only got one language to put on your resume.

Jumble code and markup together in JSX, then you can put JavaScript, ECMAScript, React/Vue, npm, node.js, babel, and possibly webpack on it.

Re: My favorite principle for code quality

#85

Post by flaviojuvenal » Wed, May 23, 2018, 3:16 AM UTC

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…

code removeability, or, write code that is easy to delete, not easy to extend: https://programmingisterrible.com/post/139222674273/write-co...

Re: My favorite principle for code quality

#86

Post by vshan » Wed, May 23, 2018, 3:56 AM UTC

Jach wrote: post #38

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

I've found Holub on Patterns to be a fantastic resource on applying GoF patterns to real world code.

Re: My favorite principle for code quality

#87

Post by gitgud » Wed, May 23, 2018, 4:08 AM UTC

kqr wrote: post #12

I agree with the general sentiment, but suggest exercising caution: Every problem can be solved by an additional layer of abstraction, except the problem of too many layers of abstraction!

Is that a quote from someone? It nicely sums up my naive experience of trying to "clean up" my code

Re: My favorite principle for code quality

#88

Post by TeMPOraL » Wed, May 23, 2018, 4:13 AM UTC

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…

> Because Customer/Vendor/Invoice was too commonplace?

I don't know which I hate more. Animals and cars, or this. And don't get me started on portfolios and stocks.

Some of us learned programming having absolutely zero clue what an invoice is. Hell, I remember being sad that all this fun knowledge is introduced with these weird, boring examples from bankers' world, as if written for PHBs.

The point is, I guess, no examples are ideal. That said, animal examples probably deserve a special place in hell, as they mess up not just with your understanding of OOP, but also biology.

Re: My favorite principle for code quality

#89

Post by flukus » Wed, May 23, 2018, 4:28 AM UTC

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.

This seems to be industry and not developer driven, business thinks it's like building a bridge and the manpower (and money) is only needed at the build stage, not the maintenance stage. After it is built money can only be directed into adding features and fixing bugs, not to improving code. This applies at both the macro (project/product) and micro (class, module) level.

We've got a weird situation where the best (best potential) devs are not financially incentivized to reach that potential, the money is in being a locust, showing up, devouring all local resources and then moving on to the next green field.

Re: My favorite principle for code quality

#90

Post by humbleMouse » Wed, May 23, 2018, 4:28 AM UTC

repsilat wrote: post #79

roenxi wrote: post #75

Earlier quoted context omitted.

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

I agree. Inheritence is useful in a very small amount of situations and can be the start of a long abstract chain of bullshit if other devs are allowed to build more funtionality on top...