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

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

281–290 of 327 posts

Re: Please do not attempt to simplify this code

#281

Post by lyu07282 »

School-Cotton wrote: post #105
refulgentis wrote: post #96

Earlier quoted context omitted.

i honestly struggle with this because its a "i know when i see it" thing, ex. here, const boo = foo ? bar : baz suffices which brings in ~every language I know. My poor attempt at a definition, covers it in practice in languages I'm familiar, but not in theory, I assume: a language where switch statements return a value

Go doesn’t have a ternary operator, you are supposed to write something like boo := bar if foo { boo = baz } One of the many cases where Go’s designers decided they would ban something they disliked about C (in this case, complicated ternary operator chains), but thought Google programmers were too stupid to understand any idea from a more modern language than C, so didn’t add any replacement. (I’m not exaggerating o…

The second you add a tenary operator people are gonna nest them, but the same is true for if/switch/match expressions unfortunately. I don't think they meant stupid literally, it's more like KISS philosophy applied to language design for maintainablity/readability/code quality reasons. Google employs some of the smartest programmers in the world.

Re: Please do not attempt to simplify this code

#283

Post by whalesalad »

geuis wrote: post #195

Joined a new company recently. They kept telling me their codebase was a mess. Yet I've been finding it to be remarkably refreshing. There are extensive comments everywhere. Lots of white space (remember to let your code breathe). Existing linting policies are extensive and thorough. The code is well structured and remarkably easy to follow through where that does what. I think it helps that it's a very small team wi…

This is a great sign because it shows humility of the engineering team.

Re: Please do not attempt to simplify this code

#284

Post by lyu07282 »

wouldbecouldbe wrote: post #254
nimih wrote: post #144

Earlier quoted context omitted.

If you think nginx is the right tool for solving problems like container deployment, service discovery, cluster scaling, and secret management, then I suppose it's not surprising that you think Kubernetes "crashes all the time" and that a 1 year rolling support window for software releases is an insurmountable obstacle. Kubernetes has a lot of genuine issues and rough edges, but you're kind of showing your ass when y…

There are just very few applications that actually need all of this. maybe 1 tot 0.1%, for instance vercel might need it. But 95-99% can just run on several "simple" servers & keep deployment times within minutes and no complicated stuff needed. Yet Kubernetes get's pushed all the time.

I don't know about that, I've found even simple applications need things like blue/green deployments and kubernetes makes that very easy and robust.

Re: Please do not attempt to simplify this code

#285

Post by runevault »

lyu07282 wrote: post #280
runevault wrote: post #138

Earlier quoted context omitted.

As someone who writes a fair bit of c# making switch and if's into expressions and adding Discriminated Unions (which they are actually working on) are my biggest "please give me this." Plus side I dabble in f# which is so much more expressive.

Same for me in the Scala vs. Java world, it's hard once you get used to how awesome expressions over statements and algebraic data types/case enums/"discriminated unions" are. But I haven't done much C# (yet) myself, could you clarify for me: does C# have discriminated unions? I didn't think the language supported that (only F# has them)?

The c# team is working on a version of them they are calling Typed Unions, not guaranteed yet but there is an official proposal that I believe is 2 weeks old.

https://github.com/dotnet/csharplang/blob/main/proposals/Typ...

Re: Please do not attempt to simplify this code

#286

Post by School-Cotton »

lyu07282 wrote: post #281
School-Cotton wrote: post #105

Earlier quoted context omitted.

Go doesn’t have a ternary operator, you are supposed to write something like boo := bar if foo { boo = baz } One of the many cases where Go’s designers decided they would ban something they disliked about C (in this case, complicated ternary operator chains), but thought Google programmers were too stupid to understand any idea from a more modern language than C, so didn’t add any replacement. (I’m not exaggerating o…

The second you add a tenary operator people are gonna nest them, but the same is true for if/switch/match expressions unfortunately. I don't think they meant stupid literally, it's more like KISS philosophy applied to language design for maintainablity/readability/code quality reasons. Google employs some of the smartest programmers in the world.

Nesting them is not so bad if the syntax makes it obvious what the precedence is, which isn't true of C, but is of Rust for example.

Anyway, complicated code should be avoided whenever possible, true, but banning the ternary operator (and similar constructs like match/switch statements as expressions) does nothing to make code simpler. It just forces you to transform

    let x = (some complicated nested expression);
into

    var x;
    // (some complicated nested tree of statements where `x` is set conditionally in several different places)

Re: Please do not attempt to simplify this code

#287

Post by Nevermark »

thaumasiotes wrote: post #215
ElFitz wrote: post #213

Earlier quoted context omitted.

That would be the purpose of formal proofs, wouldn’t it? Formal proofs may not be silver bullets, and we’re never safe from a faulty implementation of the proven algorithms, but this quanta article on a DARPA project showed impressive results [0]. There’s also AWS’ use of TLA+ [1]. [0]: https://www.quantamagazine.org/formal-verification-creates-h... [1]: https://news.ycombinator.com/item?id=22082869

> Formal proofs may not be silver bullets, and we’re never safe from a faulty implementation of the proven algorithms You also aren't safe from misunderstanding what it is that you've proven about the program. Which is actually the same problem as other software bugs; you have a specification of something , but you don't know what it is that you've specified, and you wish it were something other than what it is.

Too true. When we translate complex concepts to code & math, either may inadvertently not be exactly what we wanted.

Interesting to think about a formal code verification system that maintained a connection between all four prime artifacts: natural language description of problem as understood & intended solution, vs. code and the properties actually verified.

Re: Please do not attempt to simplify this code

#288

Post by knappe »

marcus_holmes wrote: post #203
jjnoakes wrote: post #187

Earlier quoted context omitted.

The why can also go out of date. Maybe not as frequently? I don't have a great intuition for the ratio, but it is certainly more often than never.

I dunno, the "why" for me is "why are we doing this, and doing it this way?". If that changes, but somehow the comment isn't changed, that would feel really strange. It's not just tweaking a few lines, it's rewriting the whole routine. If all the code changed but not the comment, that would have to be deliberate, and definitely picked up in code review. Though, obviously, accidents happen, etc. But then that also hap…

So I actually find this helpful because if the why doesn't match the what (code), I know to look back at the history of changes and see why there is a mismatch. This is honestly a great signal that something might have gone sideways in the past while I'm trying to triage a bug or whatever. So even if the comments are out of date, they're still helpful, because I know to go look at why they're out of sync.

Re: Please do not attempt to simplify this code

#289

Post by consteval »

jgwil2 wrote: post #276
dijksterhuis wrote: post #268

Earlier quoted context omitted.

> humans make mistakes All software is built by humans in some way. All software has mistakes. Perfection is an impossible goal.

Yeah but there's a fundamental difference between something like tests that can be checked automatically and comments, that have to be checked manually. Because of this, it can be assumed that comments will eventually go out of date.

Tests only test functionality, they don't test business context. Comments explain business context.

For example, "we have this conditional here because Business needs this requirement (...) satisfied for this customer"

Your comment can test the logic works correctly. But someone coming in, without the comment, will say "why are we doing this? Is this a bug or intentional? Is the test bugged, too?"

Now, they'll see it's intentional and understand what constraints the code was written under. Your test can't send a slack message to a business analyst and ask them if your understanding is correct. The original dev does that, and then leaves a comment explaining the "why".

Re: Please do not attempt to simplify this code

#290

Post by consteval »

ungreased0675 wrote: post #266
spacemadness wrote: post #132

Earlier quoted context omitted.

Every time some code reviewer comes into my PR and says something along the lines of "you know you can just write it this way" where "this way" means obfuscating the code because "clever" and "shorter," I die a little on the inside. This is from experienced devs who should know better. At one point I wrote a comment write above a section I knew would be targeted by this kind of thinking explaining it must be written…

I’m not a dev, but I manage them. On one team they were spending many hours on code golf and nothing was being built. I pushed the devs to passing testing=PR accepted. In your opinion, what problems might come from removing opinionated code reviews? Why do some reviewers gravitate toward “Here’s how I would have written it?”

I think the biggest problem that can come of it is lack of standards.

Each dev has their own way of writing things, their own little language. To them it is perfect. And it all works, passes tests. But, if you let them do this then your code becomes sloppy. Styles go in and out. Like reading a book where every other paragraph is written by a different person, and none of them talked to each other. Sometimes you get PascalCase, sometimes camel_case, sometimes snakeCase. Sometimes booleans are real bools, sometimes they're "Y" "N" (yes, real) or sometimes they're ints. Sometimes functions take in a lot of arguments, sometimes they take in a struct with options. Sometimes missing data is nullable, other times it's an empty string, othertimes its "N/A". And on and on.

You can enforce a lot of this through automatic linters, but not all. You require a set standard and the PR procedure can enforce the standard.

Post reply on HN