Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write code. Not too much. Mostly functions.

brandons.me

Post reply on HN
Print view View original

91–100 of 362 posts

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

#91

Post by chrisweekly »

bitexploder wrote: post #87
abledon wrote: post #68

Earlier quoted context omitted.

> It's like trying to read a book with each sentence reference a different page. Yes!!! I've been trying to teach Juniors that if the function itself has 4 levels of abstraction, even if the names are readableFunctionThatDoesXwithYSideEffect ..... it is harder to understand, Ctrl+clicking downards into each little mini-rabbit -hole. Just keep the function as a 80-liner, not a 20-liner with 4 levels of indirection w/…

The key concept they always helps me is to minimize side effects per function. One thing goes in, one thing comes out (in an abstract sense). Multiple side effects starts getting dodgy as it makes the function harder to predict and reason about. I do err for longer easier to read functions. And don’t compose into functions until it’s clear you will actually reuse the code or you actually need to reuse it :) DRY is go…

Yes! "AHA" (Avoid Hasty Abstractions) is the remedy to too much "DRY".

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

#92

Post by gcpwnd »

dcolkitt wrote: post #57
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 disagree. I think the central thesis of Clean Code still holds up. You should never mix layers of abstraction in a single function. That more than anything is what kills readability, because context switching imposes a huge cognitive load. Isolating layers of abstraction almost always means small, isolated, single-purpose functions.

Yes context switching is a huge cognitive load. Abstractions enforce context switching.

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

#93

Post by nkuttler »

ludocode wrote: post #63
ZephyrBlu wrote: post #51

Earlier quoted context omitted.

I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.

I think it's more that bad programmers focus on surface details like code style. All too often I've seen a code review of a complex feature get derailed by nitpicking of inconsequential things like variable names, formatting, etc. I rarely comment on code style for this reason. I want the review to focus on functionality, not style. I don't really believe the notion "imperfect code style is a code smell" anyway.

> I don't really believe the notion "imperfect code style is a code smell" anyway.

Blaming developers for something that can be automated? Yeah, something is off here, though not necessarily the review.

> nitpicking of inconsequential things like variable names

To me it sounds like a good thing when there's nothing else to comment on. Making code more readable is a win for everybody.

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

#94

Post by the_cat_kittles »

modeless wrote: post #5
83457 wrote: post #2

And functions should be no bigger than your head.

This is my least favorite programming advice. Splitting functions for no reason other than "it's too long" is a bad practice. https://news.ycombinator.com/item?id=25263488

ive developed a defacto rule of thumb / intuition that a function size should basically be as big as it can be without being inconvenient to test. which means that its pretty small most of the time

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

#95

Post by koolba »

nomel wrote: post #44
bitexploder wrote: post #37

Earlier quoted context omitted.

As I get older my code gets a little more verbose and a little less idiomatic to the language I am writing. I’ve been writing code, starting with C, since 95. Mostly Python these days, but I try to make it clear and easy read. Mostly for myself. Future me is always happy when I take the time to comment my overarching goals for a piece of code and make it clean and well composed with enough, but not too many, function…

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

> In my experience, code with too many functions is more difficult to grok than spaghetti code.

Because it is, just on multiple plates.

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

#96

Post by ZephyrBlu »

ludocode wrote: post #63
ZephyrBlu wrote: post #51

Earlier quoted context omitted.

I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.

I think it's more that bad programmers focus on surface details like code style. All too often I've seen a code review of a complex feature get derailed by nitpicking of inconsequential things like variable names, formatting, etc. I rarely comment on code style for this reason. I want the review to focus on functionality, not style. I don't really believe the notion "imperfect code style is a code smell" anyway.

I have a contrary view on code style. If there's no semblance of consistency to the code you write, how can you possibly formulate a consistent and sensible architecture?

The style itself is inconsequential, but no consistent style is a red flag to me.

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

#97

Post by u801e »

nx7487 wrote: post #50
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…

> In my experience, code with too many functions is more difficult to grok than spaghetti code. In a way, it kind of _is_ spaghetti code. Even if there's no back references, it turns a single train of thought into a string of entrances and exits.

"Lasagna code" might be a better term.

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

#98

Post by bob1029 »

tomrod wrote: post #19
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…

What if code is needed to explore the problem domain? There is utility in discovery, especially for analysts/data scientists who tend to write a surprising amount of code.

This is a fair argument for taking a stab in the dark. That's certainly how we started out.

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

#99

Post by whoisthemachine »

brundolf wrote: post #75
whoisthemachine wrote: post #53

Great post. I would even go as far as to amend your last comment to be closer to its inspiration: > Code only those things that your grandparents would have coded Software has been around long enough that some people's grandparents were coding, but due to the limitations of many of the systems at the time, functional, simple programs were often the craziest they could get.

My impression of early coding (could be wrong) is that you mostly couldn't afford to write in functional terms, because you had to carefully manage things like memory usage. Assembly, at least, is about as far from FP as you can get

Not in practical terms - by their very nature, registers must be mutated during a non-trivial program. Still - processor instructions are functional by nature: for example, an ADD op requires two register inputs and one register output. The assembly I worked with in university also includes the ability to create callable procedures. So even when designing assembly code, it pays to think in functional terms, although as stated earlier, registers are mutable by nature. My point was the constraints of the time kept developers from making things too complicated, so their programs often followed functional like, simple designs - see the POSIX utilities for example.

Still, Lisp was created in 1958 [0], so it's definitely likely some folks grandparents were programming in it :)

[0] https://en.wikipedia.org/wiki/Lisp_(programming_language)

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

#100

Post by lookdangerous »

kortex wrote: post #58
kccqzy wrote: post #46

Earlier quoted context omitted.

GOPATH is hated because it's poorly thought-out. It's poorly thought-out because Go is designed by Google, who uses Bazel for dependency management. GOPATH is only there because you can't expect everyone to adopt Bazel in order to adopt Go, so some half-assed solution gets designed to get the language out the door. In simpler terms, the people who designed the language don't use GOPATH at all. That's why it's terribl…

I don't think GOPATH is poorly thought out at all. Dependency-environment-locating is a PITA. Off the top of my head, I can't think of a single package management system that doesn't use universal installs, FOO_PATH or "giant local dump per project". Universal: - apt, yum, brew Team PATH: - GOPATH - CMAKE_PREFIX_PATH - PYTHONPATH (which Conda, virtualenv, etc modify) - CARGO_HOME Team redundant local blob: - Node - p…

Is your home dir chock full of namespace folders?
Post reply on HN