My favorite principle for code quality • Hacker News Board

Re: My favorite principle for code quality

#21

Post by lttlrck » Tue, May 22, 2018, 8:28 PM UTC

et1337 wrote: post #6

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.

Algorithms + Data Structures = Program

This was something that was stressed by my mentor, who was a mathematician turned programmer and a big fan of Niklaus Wirth. It has proven valuable to me on numerous occasions and informs design.

https://en.m.wikipedia.org/wiki/Algorithms_%2B_Data_Structur...

Re: My favorite principle for code quality

#22

Post by dmytroi » Tue, May 22, 2018, 8:31 PM UTC

The post indirectly suggest creating domain specific language for solving dashboard presentation problem. In my opinion this shifts engineers focus to solve problems with-in provided domain specific language, which in the end resolves in job security, as non-senior engineers will not "dare" to touch "the framework". Whole situation, in my opinion, results in "everything working on paper" (aka tests, good design, etc) while in reality nothing works and as project progresses engineers get a feeling that "nothing can be done". I would just remove "numWords = countWords();" line and move on. There is no need to invent domain specific language when just programming language is sufficient. I would love engineers to be more reasonable and aware of DSL's trade off.

Re: My favorite principle for code quality

#23

Post by jpochtar » Tue, May 22, 2018, 8:31 PM UTC

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 thankfully it's all in one place.  
    if (lastCachedTime  countUsers());
    print("Articles written: " + cached("numArticles", => countArticles());
    print("Words written: " + cached("numWords", => countWords());
  }

This achieves the same "Embedded Design" goal. If you squint, it's actually virtually the same as the DashboardStatComputation/DashboardStat/Dashboard the author comes up with, where each lambda in the displayDashboard function is corresponds to a DashboardStatComputation.

I prefer this lambda-based design because it reifies the "form" into a single, callable, function: cached(). If you want to use the idea of cached(), you don't have to subclass anything or know about its implementation details— just call it.

(PS. the code's even nicer in CoffeeScript)

Re: My favorite principle for code quality

#24

Post by yani » Tue, May 22, 2018, 8:31 PM UTC

vorpalhex wrote: post #14

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.

> 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?

Re: My favorite principle for code quality

#25

Post by Silhouette » Tue, May 22, 2018, 8:31 PM 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…

It's a 'frggin stats page where a developer forgot to remove a call.

And a call that any decent set of tools would surely have highlighted as redundant at that.

I'm all for being clear about the design of a program, but I don't think the example here is convincing, and I agree with the parent that over-engineering can itself damaging.

Re: My favorite principle for code quality

#26

Post by aero142 » Tue, May 22, 2018, 8:36 PM UTC

sp332 wrote: post #2

Robert Piersig illustrates these higher-level concepts, which he calls forms, Pretty sure that's attributed to Plato. Well I guess he called them είδε but he couldn't wait around for English to get invented.

I think that was one of the great things about Zen. It was an unreliable narrator who had megalomania. At one point, he acknowledges that most of what he is stating is pulled from older greek philosophy that he didn't bother to learn properly but then continues to claim to invent new philosophy through the story.

Re: My favorite principle for code quality

#27

Post by erpellan » Tue, May 22, 2018, 8:36 PM UTC

Ask yourself what assumptions you are baking into the design. Can you make them more explicit? How likely are they to change? Where multiple approaches are on the table, favour the ones with the fewest assumptions. Be especially critical where cardinality is concerned. It's much easier to go from n to n+1 than from 1 to 2.

Re: My favorite principle for code quality

#28

Post by farrisbris » Tue, May 22, 2018, 8:37 PM UTC

vorpalhex wrote: post #14

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.

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

> Many people who program in PHP learned it as a first language, hacked together programs in it, and probably used hack together libraries and tooling.

This describes me very well, and i don't think i'm alone. When i look back at my(very early, first language) PHP code it looks horrible. A lot of it is just copy pasted code from random websites telling me that that it does what i wanted it to. Which is a pretty good description of me at a young age trying/learning to program by internet. I don't use PHP today, and i really don't want to, but i suspect that is in some part due to me struggling with stuff i never understood when i was doing it and developing a distaste for it looking back at my bad code from that time without realizing it could be done differently/in a way fairly close to what i do in my current work-language. I just wanted to make my WoW dkp page work and searched the internet when wondering how to and ended up writing really bad code. It still worked pretty good and i had fun doing it but i never considered writing PHP again once i moved on.

Re: My favorite principle for code quality

#29

Post by oldgeezr » Tue, May 22, 2018, 8:38 PM 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…

+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.

Re: My favorite principle for code quality

#30

Post by yani » Tue, May 22, 2018, 8:39 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.

Just give yourself time to write and maintain PHP code for over one year and you will find the answer. PHP does not have a debugger nor a test runner nor a profiler built in. Someone will say use xdebug and phpunit and etc.. well I want tools that ship with the language and are not slow like phpunit...