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

Push Ifs Up and Fors Down

matklad.github.io

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Push Ifs Up and Fors Down

#201

Post by phatskat »

xp84 wrote: post #33
jt2190 wrote: post #19

Earlier quoted context omitted.

Code scanners reports should be treated with suspicion, not accepted as gospel. Sonar in particular will report “code smells” which aren’t actually bugs. Addressing these “not a bug” issues actually increases the risk of introducing a new error from zero to greater than zero, and can waste developer time addressing actual production issues.

I agree with you. Cyclomatic complexity check may be my least favorite of these rules. I think any senior developer almost always “knows better” than the tool does what is a function of perfectly fine complexity vs too much. But I have to grudgingly grant that they have some use since if the devs in question routinely churn out 100-line functions that do 1,000 things, the CCC will basically coincidentally trigger and…

I get that, and I think it’s a fine check for junior devs especially. In my experience, mostly with PHP mess detector, Cyclomatic Complexity smells typically manifest as nested conditionals. I’m at a point now where I try to keep that minimal myself, but I have peers that often have these diving sets of if statements that irk me. I’d rather invert a conditional and return early if needed, or at least separate the logic so that there’s maybe two levels at most.

I do agree that, in general, a senior engineer should be able to suss out what’s too complex. But if the bar is somewhat high and it keeps me from sending a PR back just for complexity, that’s fine.

Re: Push Ifs Up and Fors Down

#202

Post by phatskat »

password4321 wrote: post #99
jt2190 wrote: post #19

Earlier quoted context omitted.

Code scanners reports should be treated with suspicion, not accepted as gospel. Sonar in particular will report “code smells” which aren’t actually bugs. Addressing these “not a bug” issues actually increases the risk of introducing a new error from zero to greater than zero, and can waste developer time addressing actual production issues.

The tools are usually required for compliance of some sort. Fiddling with the default rules is a baby & bathwater opportunity similar to code formatters, best to advocate for a change to the shipping defaults but "ain't nobody got time for that"™.

I like the approach of “if there is no standard, give everyone a week to agree and if they don’t just pick something.” I’ve built too many sheds with “tabs or spaces?”

Re: Push Ifs Up and Fors Down

#203

Post by jonahx »

BoorishBears wrote: post #199
jonahx wrote: post #160

Earlier quoted context omitted.

I feel this kind of critique, which I see often as a response to articles like this, is so easy as to be meaningless. How is one supposed to ever talk about general principles without using simplified examples? Aren't you just saying "Real code is more complicated than your toy example"? Well sure, trivially so. But that's by design. > Perfect example is the "redundancies and dead conditions" mentioned: we're making…

Well I guess some comments need to be considered in totality, rather contextomies that enforce whatever point you're trying to make :) I spelled out the problem pretty clearly. > I used to try and form these kinds of rules and heuristics for code constructs, but eventually accepted they're at the wrong level of abstraction to be worth keeping around once you write enough code. It's the wrong level of abstraction to f…

Because that was the only evidence you offered to back up the claim you just quoted. I understood the claim... it might be interesting if you presented some specific example of your own as counter-evidence, instead of straw-manning the article's intentionally simple example as too simplistic.

Your argument sounds like, "I'm so smart and enlightened, I've moved beyond simple heuristics like this." Okay, but the author is also a smart, experienced programmer and is apparently still finding them useful. I am also experienced, and personally find them useful.

I'm not against some argument that there is actually an even better, deeper way to look at these things. But you didn't make that argument. And, perhaps unfairly (you tell me) I suspect your response to that will be that it's all too gossamer, or would take too long to explain....

Re: Push Ifs Up and Fors Down

#204

Post by bognition »

kazinator wrote: post #151
bognition wrote: post #132

Earlier quoted context omitted.

If you are explicitly calling authenticate() for each api, you’re doing it “wrong”. At that point you want implied authentication not explicit authentication. Why not move it to some middleware that gets called in every api call?

Because then you are calling middleware_caching_auth_broker() from 37 places instead of authenticate(). Just the name has changed, not the 37.

No that’s not how this works. You register the middleware with your web framework and it gets called as part of all web requests before the request hits your endpoints. This allows you to trust that authentication has been called for all api calls

Re: Push Ifs Up and Fors Down

#205

Post by kazinator »

cakealert wrote: post #200
kazinator wrote: post #196

Earlier quoted context omitted.

ISO C allows: free(NULL); // convenient no-op, does nothing fflush(NULL); // flush all streams; done implicitly on normal exit time(NULL); // don't store time_t into a location, just return it strtol(text, NULL, 10); // not interested in pointer to first garbage char setbuf(stream, NULL); // allocate a buffer for stream realloc(NULL, size); // behave like malloc(size) and others. More examples in POSIX and other APIs…

I'm sorry. Are you claiming the people who designed those functions made good choices? They altered the behavior of the function considerably for a single input value that is more likely to be a bug than not.

Yes. I will probably continue to make similar choices of the future.

Re: Push Ifs Up and Fors Down

#206

Post by ashf023 »

IMO pushing ifs up makes sense when the condition is enforceable by the type system, e.g. in the Option vs Walrus example, and when doing so makes the function's purpose more clear, or gives callers more flexibility. I think it's generally intuitive when writing code - can I use the type system to guard this rather than checking in my function, and should this function decide what happens in the unexpected cases?

Pushing fors down is usually not that relevant in Rust if all it achieves is inlining. The compiler can do that for you, or you can force it to, while improving reusability. It can make sense if there's more optimization potential with a loop e.g. lifting some logic outside the loop, and the compiler doesn't catch that. I also would avoid doing this in a way that doesn't work well with iterators, e.g. taking and returning a Vec.

Re: Push Ifs Up and Fors Down

#207

Post by philwelch »

tsurba wrote: post #176
philwelch wrote: post #164

Earlier quoted context omitted.

That sounds like the programming equivalent to thinking that food just comes from the grocery store.

And going to a grocery store instead of 37 individual farmers…?

Is fine, but don’t pretend the farmers don’t exist and aren’t part of the system.

Re: Push Ifs Up and Fors Down

#208

Post by BoorishBears »

jonahx wrote: post #203
BoorishBears wrote: post #199

Earlier quoted context omitted.

Well I guess some comments need to be considered in totality, rather contextomies that enforce whatever point you're trying to make :) I spelled out the problem pretty clearly. > I used to try and form these kinds of rules and heuristics for code constructs, but eventually accepted they're at the wrong level of abstraction to be worth keeping around once you write enough code. It's the wrong level of abstraction to f…

Because that was the only evidence you offered to back up the claim you just quoted. I understood the claim... it might be interesting if you presented some specific example of your own as counter-evidence, instead of straw-manning the article's intentionally simple example as too simplistic. Your argument sounds like, "I'm so smart and enlightened, I've moved beyond simple heuristics like this." Okay, but the author…

You seem incapable of speaking without putting words in my mouth.

It doesn't get tedious going through life like that, speaking for two?

Re: Push Ifs Up and Fors Down

#209

Post by sharno »

andyg_blog wrote: post #21

A more general rule is to push ifs close to the source of input: https://gieseanw.wordpress.com/2024/06/24/dont-push-ifs-up-p... It's really about finding the entry points into your program from the outside (including data you fetch from another service), and then massaging in such a way that you make as many guarantees as possible (preferably encoded into your types) by the time it reaches any core logic, especially…

That's almost the same thing as parse don't validate: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Post reply on HN