My favorite principle for code quality • Hacker News Board

Re: My favorite principle for code quality

#101

Post by milesvp » Wed, May 23, 2018, 6:57 AM UTC

greggyb wrote: post #61

ljm wrote: post #55

Earlier quoted context omitted.

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…

This makes me think of a good thinking talk, with a quote I pull out from time to time: > I hate code, and I want as little of it as possible in our product. http://pyvideo.org/pycon-us-2012/stop-writing-classes.html

I was always disappointed I couldn't find more talks by Jack Diederich after watching this one. His approach was so practical compared to so much programming advice out there. I see now that he's got a few more talks linked from here.

I know how I'll be spending a few hours in the next few days. Thank you for reminding me of his talk!

Re: My favorite principle for code quality

#102

Post by auxbuss » Wed, May 23, 2018, 6:57 AM UTC

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…

There's an excellent discussion on this topic in the sample chapter, Rediscovering Simplicity[0], from Sandi Metz's book, 99 Bottles of OOP[1]. I often use it as a source for discussion with devs.

[0] https://www.sandimetz.com/99bottles/sample

[1] https://www.sandimetz.com/99bottles

Re: My favorite principle for code quality

#103

Post by sseth » Wed, May 23, 2018, 7:42 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!

The version i like goes something like this :

Any problem of abstraction (in programming) can be solved by adding a layer of indirection. Any problem of performance can be solved by removing a layer of indirection.

Re: My favorite principle for code quality

#104

Post by j_tomanik » Wed, May 23, 2018, 7:42 AM UTC

gitgud wrote: post #87

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

https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...

Re: My favorite principle for code quality

#105

Post by mikekchar » Wed, May 23, 2018, 8:11 AM UTC

sooheon wrote: post #94

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.

I have promised to, but have not followed through with that promise. One of these days maybe...

Re: My favorite principle for code quality

#106

Post by antirez » Wed, May 23, 2018, 10:38 AM UTC

SNACKeR99 wrote: post #67

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 find this true, and depressing at the same time. The amount of curation needed for a constantly evolving code base is vastly underestimated by most, even to achieve the modest design goals (IMO) that you are espousing.

Yep, you have to babysit the code forever or it dies...

Re: My favorite principle for code quality

#107

Post by davidhyde » Wed, May 23, 2018, 12:49 PM UTC

"Abstract early" is just plain bad advice because you usually don't know the full problem up front. Better advice would be to write code that lends itself resilient to refactoring (i.e. it is easy to refactor and won't break in unexpected ways when you do so)

Additionally, the authors "better" design now abstracts the primary performance problem out of sight of the developer. The main problem I see is that they are making multiple passes through the data to extract different metrics. By abstracting early they miss the opportunity to improve the performance by calculating all the metrics in one pass. The new design has hidden the root cause of the problem and prevented a developer from fixing the core problem without chucking out the entire design.

Re: My favorite principle for code quality

#108

Post by ninkendo » Wed, May 23, 2018, 1:14 PM 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’ve only ever seen inheritance make sense in UI toolkits. That’s literally it.

It’s like if someone took the cascading idea of CSS and decided “this works so well for UI styling, let’s build a language paradigm out of it and convince people they need to express every problem in terms of it.”

Re: My favorite principle for code quality

#109

Post by wsy » Wed, May 23, 2018, 1:24 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…

You need to get your domain concepts right, and to let your code reflect these concepts. Then, fewer bugs occur because mapping a business request to code becomes a simpler task. Also, it becomes easier to understand and fix bugs, because again the mental mapping from customer-observable behavior to code is easier.

Still, I agree with the advice to not introduce these abstractions early, because you will get them wrong.

Re: My favorite principle for code quality

#110

Post by Izkata » Wed, May 23, 2018, 1:30 PM UTC

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…

This is similar to what I was thinking, but in python and remaining more object-oriented, its API would look something like this: (with essentially the same invalidation logic in the init)

   cache = GroupedCache(key="dashboard_stats")
   print("Total users: {}".format(cache.get(countUsers))
   print("Articles written: {}".format(cache.get(countArticles))
   print("Words written: {}".format(cache.get(countWords))

To me this would make it more apparent when reading the code that these should all be cached together (your functional one, with a different cache strategy, makes it look like it's acceptable for them to be cached for 1 hour, but offset from 30 minutes from each other due to external circumstances), and while pretty irrelevant for this particular example, would avoid the miniscule race condition if the clock ticks over midnight between Total Users and Articles Written.