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

271–280 of 647 posts

Re: Please do not attempt to simplify this code

#271

Post by dfox »

pbhjpbhj wrote: post #128
blueside wrote: post #81

Earlier quoted context omitted.

All the better hamburgers cost more

Not true in the UK, McDo really ain't that cheap anymore (or perhaps I'm poorer than I think). The better burgers made by large commercial chains are more expensive though.

That largely depends on supply and demand in the particular locality. Primary value of McD is that they are global enough that such effects are mostly averaged out and the core products are essentially same globally and the pricing is consistent at least on country level. One thing that recently surprised me is that KFC does not work in the same way and the menu is totally different across not only EU countries, but even franchise holders in same country.

Re: Please do not attempt to simplify this code

#272

Post by Etheryte »

yongjik wrote: post #148

Obviously I'm not the intended audience, but I'm not sure it's wise to have CloudVolumeCreatedForClaimNamespaceTag, CloudVolumeCreatedForClaimNameTag, and CloudVolumeCreatedForVolumeNameTag in the same file. This is almost the worst of both worlds: the trouble of wading through a pile of words, together with the lack of clarity.

While I understand your sentiment, I don't think it's a real issue with pretty much any modern IDE.

Re: Please do not attempt to simplify this code

#273

Post by dfox »

kbumsik wrote: post #259
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

> This is a feature of several (mostly functional) programming languages This is just one of a common practice of programming, not a feature of functional languages. These practices are not even "reinventing the wheel". I mean, this is obvious in many areas: from implementing complex logics like Kubernetes to making hardware drivers in C. Programming languages themselves can't automagically ensure every single condit…

This is one of the painfully obvious facts that tend to be totally ignored by most. Even if you formally verify all of you code it does not mean that you have covered all the possible states of the outside world. And this can mean both unexpected states on the outside and unexpected hardware failures.

On one project I work with guy with significant railway signalling experience and this is one of the issues that I'm somewhat unable to explain to him. Probably because our product's design target is not to fail-fast-and-safe but fail-secure.

Re: Please do not attempt to simplify this code

#274

Post by zorga »

startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

> do other HNers also feel that a high comment:code ratio probably indicates quality?

Nope, imho code with lots of comments is generally crappy code. It's littered with comments to explain the sloppy code they couldn't make clear because they're bad programmers. Good programmers use few comments, write simple clear code that doesn't require explaining, and leave comments about why something was done rather than simply trying to explain what the code does.

Code never lies, comments often do; don't trust comments that explain the code.

Re: Please do not attempt to simplify this code

#275

Post by lincpa »

I tend to wrap the if statement in the function as much as possible, so that the code as a whole presents a sequential pipeline structure. Keep the code concise and readable.

MyBlog: The Pure Function Pipeline Data Flow https://github.com/linpengcheng/PurefunctionPipelineDataflow

Re: Please do not attempt to simplify this code

#277

Post by 3pt14159 »

dragonwriter wrote: post #232
Klathmon wrote: post #21

I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing,…

> I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. I kind of see it as the opposite: “space shuttle style” is code that adheres to heavyweight rules that most software development has abandoned in favor of a more improvisational style. But in either case it illustrates that co…

I've had this latent thought for a while that I'm finally putting to words:

The complexity goes somewhere.

It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure!

But something, somewhere is handling the complexity and it is doing so as a partial function to the economic importance of the software to the stakeholders of the software.

Re: Please do not attempt to simplify this code

#278

Post by [deleted] »

EpicEng wrote: post #266
skybrian wrote: post #254

Earlier quoted context omitted.

I don't understand the objection to having more, smaller files, at least in Go where they can all be in the same package. Once two functions are too far apart to be on screen at the same time, jumping back and forth between two functions in the same file doesn't seem any easier than switching between different files. If anything, switching between two different files is easier since they each get an editor tab. On th…

For me, it's less about number of files than it is "hoeany files do I have to open to figure out how something works? How many levels of indirection do I have to keep in my head?" I started out writing low-ish level code. Motion control, image processing, digital imaging, and the application level code that coordinated it all. I've steadily moved up the abstraction tree over the last 13 years and there's one thing I…

[deleted]

Re: Please do not attempt to simplify this code

#280

Post by innomatics »

geofft wrote: post #55
kraftman wrote: post #45

Earlier quoted context omitted.

'A comment is a failure to express yourself in code. If you fail, then write a comment; but try not to fail.' - https://twitter.com/unclebobmartin/status/870311898545258497... And a bit more on the same from clean code: http://www.kyleblaney.com/software-blog/2012/6/29/comments-a...

How do you successfully express "We need to treat all transactions on February 29 as happening on February 28, see customer ticket #4321 for rationale" in code?

I think it's fair to express rationale in comments, but the following works for me without comment:

  transactionsLeapDayAdjusted = transactions.map(t => t.date == '29-Feb' ? {date: '28-Feb', ...t} : t)
One thing I always push back on is references to ticket numbers or other external systems (except perhaps e.g. ISO standards). Repos should be self contained and perpetual. One might not have access to the ticket system now, or ten years from now.
Post reply on HN