My favorite principle for code quality

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.

Re: My favorite principle for code quality

#5

Post by everdev » Tue, May 22, 2018, 7:53 PM UTC

> 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 requirements or application states.

Yes, planning reduces bugs, but bugs are still inevitable no matter what software design process we use.

Re: My favorite principle for code quality

#6

Post by et1337 » Tue, May 22, 2018, 8:04 PM UTC

I prefer a more focused version of this principle: you should organize your data in a way that makes the design apparent. The code will follow later.

This principle still works with the author's example. Most of the refactoring he did boiled down to modeling the data more accurately.

Re: My favorite principle for code quality

#7

Post by extrapickles » Tue, May 22, 2018, 8:05 PM UTC

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…

I agree with you.

Issues with communication were directly attributable to ~1/3 of the bugs in software I've worked on. These bugs are unfixable with any process as they are caused by not stating a requirement/feature/bug in a way that is understood perfectly by the developer writing the code.

Re: My favorite principle for code quality

#8

Post by krona » Tue, May 22, 2018, 8:08 PM UTC

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.

Re: My favorite principle for code quality

#9

Post by joslin01 » Tue, May 22, 2018, 8:11 PM UTC

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.

Re: My favorite principle for code quality

#10

Post by icedchai » Tue, May 22, 2018, 8:11 PM UTC

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.