Write code. Not too much. Mostly functions. • Hacker News Board

Re: Write code. Not too much. Mostly functions.

#291

Post by sethammons » Tue, Dec 22, 2020, 1:17 PM UTC

Ma8ee wrote: post #153

nomel wrote: post #44

Earlier quoted context omitted.

> well composed with enough, but too many, functions. In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks. > As I get older my code gets a little more verbose I've seen too many of my previous projects die right when I moved on. Now I tend…

On the other hand, no abstractions is like reading a book where each and every thing is spelled out in outmost detail. Instead of telling you “I’m fuelling the car”, I’ll tell you: “I’m walking to the entrance hall. I’m picking up the car keys. I’m putting on my shoes. I’m putting on my jacket. I’m unlocking the front door ...”. You see where this is going. And here we already assumed that things like “putting on sho…

Then you have an electric car, and you use the fuel method and add a special case for isElectric handling inside. And some other dev uses lamp.fuel since it already handled isElectric internally. But later, we have to differentiate between different types of charging and battery vs constant AC and DC power. Then someone helpfully reorganizes the code and breaks car.fuel because the car does have a battery too. And then ....

Re: Write code. Not too much. Mostly functions.

#292

Post by [deleted] » Tue, Dec 22, 2020, 1:20 PM UTC

bcrosby95 wrote: post #186

ellis-bell wrote: post #180

Earlier quoted context omitted.

Incidentally one of the biggest benefits I see of using a text editor like vim / emacs is that it really encourages good code management. It's not to save the ~10 minutes per year in faster key strokes to manipulate your code. It's about the way it shapes your thinking about how you code.

I agree to some extent. After using Intellij for about 5 years I switched to a less batteries-included code editor (currently doom emacs). I figure if I need an IDE to navigate our code as a senior developer on the project then less experienced ones don't stand much of a chance. I still use Intellij for refactoring.

[deleted]

Re: Write code. Not too much. Mostly functions.

#293

Post by bigbizisverywyz » Tue, Dec 22, 2020, 1:41 PM UTC

redisman wrote: post #163

jrott wrote: post #147

Earlier quoted context omitted.

> In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks. This is so true. The worst code that I've dealt with is the code that requires jumping to a ton of different files to figure out what is going on. It's usually easier to decompose a pil…

My experience has been that spaghetti is almost always in the real world mostly overly abstract and poorly thought out abstractions. You know you get a stack trace and you end up on a journey in the debugger for 5 hours trying to find any actual concrete functionality. Compared to someone writing inline functions that do too much, the wasted brain hours don’t even come close

It's also often very deeply nested and follows different paths based on variables that were set higher up in the code, also depending on deeply nested criteria being met. Bugs, weird states, bad error handling and resource leaks hide easily in such code.

In my experience refactoring out anything nested >3 levels immediately makes the code more readable and easier to follow - I'm talking about c++ code that I recently worked on.

Decomposing to functions and passing as const or not the required variables to functions that then do some useful work makes it clear what's mutated by the sub functions. Make the error handling policy clear and consistent.

Enforce early return and RAII vigorously to ensure that no resources (malloc,file handles,db connections, mutexes, ...) are leaked on error or an exception being thrown.

And suddenly you have a code base that's performant, reliable and comprehensible where people feel confident making changes.

Re: Write code. Not too much. Mostly functions.

#294

Post by bigbizisverywyz » Tue, Dec 22, 2020, 1:44 PM UTC

hutzlibu wrote: post #119

nomel wrote: post #44

Earlier quoted context omitted.

> well composed with enough, but too many, functions. In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks. > As I get older my code gets a little more verbose I've seen too many of my previous projects die right when I moved on. Now I tend…

"I've seen too many of my previous projects die right when I moved on. Now I tend to write code as if it were written by a beginner: verbose and boring, with no magic." Theres nothing wrong with charming magic in your code, if it really does something special and is not just used for the sake of it - it only gets into dark magic, when you forget or are too lazy to add proper documentation in the end. Which ... happen…

I once read a quote, possibly here on HN that said:

"Code first for the machines, then for others that will maintain your code and lastly for yourself."

And that I think for me nicely strikes the balance.

Re: Write code. Not too much. Mostly functions.

#295

Post by ragnese » Tue, Dec 22, 2020, 1:53 PM UTC

chriswarbo wrote: post #255

momokoko wrote: post #69

Earlier quoted context omitted.

>I don't always need to have n+1 layers in my architecture where all the layers just call the next layer anyway. This is by far the most common thing I’ve seen consistently in especially difficult to maintain codebases. Anecdotal for sure, but number 2 on that list is way behind. Extra abstractions for a future that has yet to happen and abstractions because the IDE makes it easy to click through the layers is the nu…

> Extra abstractions for a future that has yet to happen and abstractions because the IDE makes it easy to click through the layers is the number 1 by far reason I’ve seen code based be very difficult to maintain. This is always tempting. A good argument against it is to realise that future developers (us included!) will know their requirements far better than we can guess them; if code needs writing, they should do…

> The best way to help them is to avoid introducing unnecessary restrictions.

But that's the other side of the exact same coin. How do you know if a restriction today is good or bad for the future? Restrictions prevent misuse and unexpected behavior, in the good case.

Re: Write code. Not too much. Mostly functions.

#296

Post by herodoturtle » Tue, Dec 22, 2020, 1:56 PM UTC

redisman wrote: post #241

atoav wrote: post #239

Earlier quoted context omitted.

I think a good programmer should have an "intuition" whether it is worth to build an abstraction for something or not. If in doubt don't do it. If in hindsight your intuition fooled you constantly, adjust it.

I agree but it's kind of too vague to have as a company/team-wide policy

If the need / opportunity to abstract something is highly subjective then it is best left to the team lead / senior architect. For all other obvious cases having a policy as outlined above strikes a healthy balance between autonomy and uniformity.

Re: Write code. Not too much. Mostly functions.

#297

Post by rpedela » Tue, Dec 22, 2020, 2:08 PM UTC

rualca wrote: post #243

serial_dev wrote: post #17

I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…

>>It made me think about the readers of my code (...) I don't always need to have n+1 layers in my architecture where all the layers just call the next layer anyway. Your assertion doesn't make sense. N-tier architectures are primarily intended by the needs of said reader of the code, because it provides a clear understanding of how the overall code is organized. More importantly, it provides a clear idea of what cod…

In practice, it rarely turns out that way. I have to deal with large, mature Java codebases for some of my work. The good thing is that the code does just about everything well and rarely breaks. The downside is that when something does break, and I have to debug the code. At some point in the Java world, best practice became building abstraction on top of abstraction on top of abstraction. And often these abstractions just call the next abstraction. Well that makes finding the offending line of code extremely difficult and time-consuming unless you are an expert of the codebase. Had the exact same code been written with less abstractions, debugging would be a lot easier.

I am not against abstractions, but I think they lead to hard to read/debug code when overused. I think they need to be used wisely rather than the default.

Re: Write code. Not too much. Mostly functions.

#298

Post by bigbizisverywyz » Tue, Dec 22, 2020, 2:13 PM UTC

bob1029 wrote: post #11

I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…

I definitely agree with this. Some of the fasted implementations I have ever done were after spending a bit of time modelling the problem solution. Basic data flows, classes (using verb/noun parsing of the requirements doc) and system architecture were all decided before I wrote any code.

The implementation itself just flowed, allowing me to focus on smaller details that can't be modelled (e.g. error handling). By copying the design of classes and function names, I didn't have to backtrack and redo anything, I didn't have to think about names of things - which were pre decided and so consistent throughout the codebase and my code dovetailed nicely with parts that other people implemented.

Re: Write code. Not too much. Mostly functions.

#299

Post by amw-zero » Tue, Dec 22, 2020, 2:20 PM UTC

Geminidog wrote: post #113

I'll take it one step further. Don't just write pure functions. Write point free combinators. Have you guys ever wondered why no matter how much care or planning you use to organize your code when you begin a project, some time down the line you will always encounter a situation where the organizational scheme you chose is less than ideal or even flat out wrong? It's a sort of inevitable technical debt that occurs. T…

That doesn’t solve any problem that I have (or anyone has) encountered.

Re: Write code. Not too much. Mostly functions.

#300

Post by bigbizisverywyz » Tue, Dec 22, 2020, 2:26 PM UTC

Matheus28 wrote: post #121

cjohnson318 wrote: post #116

So, I have a question. I have a kind of serial number, and different systems expect slightly different formats. One system likes dashes, one doesn't, one system likes an extra two digits, while another system likes an extra four numbers. Should I write around n(n-1)/2 pure function converters between n systems? Or one class with n methods? (If you're curious, I'm talking about oil well API numbers. It's not rocket sc…

If you REALLY have to use all these different formats, I'd have one canonical one used everywhere in your app, and 2n methods to convert to different ones at api boundaries.

Another advantage of that approach is that if you make sure you always persist the serial number in the canonical format, and immediately parse the incoming value into the canonical form, then comparing 2 serial numbers is easy and consistent - including e.g. when constructing db queries.

I encountered a similar problem where an identity number could be represented in different formats, and the solution had been to store the string representation in all its glorious permutations. Doing db queries to find anything by that key was then impossible until the representation had been made consistent.

Then when e.g. creating reports for different systems we could format the output as per that systems expectation.