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

551–560 of 647 posts

Re: Please do not attempt to simplify this code

#551

Post by projektfu »

detaro wrote: post #507
projektfu wrote: post #505

Earlier quoted context omitted.

Since we're referring to Bob Martin, I suspect the answer is through a functional test that captures that requirement. Thus, if a naive editor makes a change that breaks the requirement, it will not pass the test and cannot be committed to mainline.

That catches a change, but doesn't give the reader the answer for why the code is like it is until they find the right test.

True enough, but in my limited experience it's more likely that such little requirements are hidden in code (and possibly commented) than that they have been properly captured by specifications and tests.

Re: Please do not attempt to simplify this code

#552

Post by geodel »

tracker1 wrote: post #474
TeMPOraL wrote: post #343

Earlier quoted context omitted.

Anyone who actually worked with code requiring so much jumping. I did, in an IDE, and I can tell you, jump-to-definition removes the problem of "what file do I have to open now?", but still leaves you with the questions like "where am I?", "how did I get here?" and "what was I trying to understand, again?", which you start asking yourself after ~sixth jump.

Not to language bash, but situations like this are why I avoid "enterprise" patterns and abstractions. Not that they aren't ever useful, but they're often implemented before they are needed, or not needed at all in practical terms. Some C# and Java tend to be some of the worst examples I've encountered. Even if the languages themselves can have much simpler implementations.

Java has these scaffolding developers who spend great deal of time in writing, 'ticket booking', 'toy/video stores' etc with all technology, framework, libs they are looking to learn. None of this code does anything useful but developers add to their resume claiming they developed reservation systems and e-commerce platform with mongoDB or whatever.

I'd add this kind of bullshit started directly from Sun Microsystems when they gave us Java EE blueprints to develop end-to-end enterprise solutions in all seriousness.

Re: Please do not attempt to simplify this code

#553

Post by [deleted] »

pdkl95 wrote: post #110

Ignoring the initial boilerplate (license, imports) and the request to preserve the verbose ("space shuttle") style, the first line is: // Design: // // [... 4 paragraphs of English prose // explaining goals and intent... ] That's exactly the type of comment that should be at the beginning of most files!

[deleted]

Re: Please do not attempt to simplify this code

#554

Post by vonseel »

tapland wrote: post #531
jml7c5 wrote: post #165

Earlier quoted context omitted.

As a novice programmer, I was absolutely stunned that this was not standard practice. A typical source file provides zero context, background on the subject, pointers to reference material/blog posts/books explaining the concepts, information on how it fits into the program's 'bigger picture', or (most importantly) the thought process that resulted in the file (i.e., why the choice was made to do _this_ rather than _…

> unless one is willing to spend hours of archaeological examination Currently the only person in-office over Christmas on my first software dev job. Debugging a 50k LOC COBOL beast that digs into three other beast programs and ends up in a final 20k LOC uncommented piece where things are supposed to happen and be returned back. Nothing is commented, the programs are huge and one can only debug one program at a time,…

  my first software dev job. Debugging a 50k LOC COBOL beast
We found the real MVP. tapland, what were you thinking when taking this job!?

Re: Please do not attempt to simplify this code

#555

Post by notacoward »

jnurmine wrote: post #379
TeMPOraL wrote: post #348

Earlier quoted context omitted.

I've never seen a git commit comment describing the "why" of code. "Added foo.\n\nImplemented az Bar because of blorgz." isn't nearly enough of a rationale, and that's the best description I see people making. Also, the whole point of putting something in a comment is that you have to read it when working through code around that comment. Putting a note in a commit log instead ensures that crucial information importa…

Look at projects with high discipline and experience, such as the Linux kernel. You will find plenty of "why" examples. It seems to be easy to find plenty of projects with bad Git commits though. IMO the big architectural guidelines and structuring and other highest level things and API contracts etc. should be in an external file (not code). The high-level details around a certain implementation in the commit logs f…

The problem with trying to document anything in a commit message is that a commit message can't easily and unambiguously point to the specific section of code that each part of the commit message refers to. You can get general intent in a commit message, specific details in the code, and a yawning void in between.

Sure, the back-and-forth on a mailing list or review system such as Gerrit can provide more of those direct links between code and explanation, but then it's often buried in a bunch of other discussion and dead ends. It's the "oh noes, comments can become out of date" times ten, so hardly a good alternative. And even when that's not the case, it's a horribly context-switchy way to get that information. Separating the explanation and the concrete expression just isn't a great idea. Funny how many people who would rather die than write a design spec also suggest that an even greater separation is a good thing.

Re: Please do not attempt to simplify this code

#556

Post by vonseel »

jtms wrote: post #490
ryanwaggoner wrote: post #244

Earlier quoted context omitted.

Disagree. I’m not a hardcore foodie, but I enjoy the entire spectrum of food, from fast-food to food trucks to homemade to Michelin 3-star restaurants. And sometimes I want Taco Bell, or yes, even McDonalds.

Tons of the chefs who work at or own those Michelin starred restaurants would agree with you - they almost universally love to eat low tier, mass market fast food

The fact that there is a mass(ive) market for fast food is proof alone that people like it (enough to eat it and spend their money on it). I’m with any of the posters above who like fancy burgers as well as fast-food burgers.

Where McD’s really shines, though, is their breakfast offerings. And with that said, I think I will head there now for a quick breakfast (I live ~5 blocks from McDs).

Re: Please do not attempt to simplify this code

#557

Post by yawaworhtttt »

vips7L wrote: post #250

HN: this is amazing! Everyone should be writing code like this! Also HN: c++ and java are awful! They're so verbose and I have to type so much!

What if I actually wanted the ability to get a thing going and quickly working within a few lines, while also being able to spell things out as needed when the use case arises? Crazy I know.

Re: Please do not attempt to simplify this code

#558

Post by barrkel »

lmm wrote: post #550
barrkel wrote: post #521

Earlier quoted context omitted.

> Kubernetes exists to solve problems that people using better languages don't generally have This statement doesn't make sense, and the arrogant tone just stinks of ignorance. Kubernetes isn't perfect, but if there's better provider-agnostic language-agnostic way to dynamically scale an application written in heterogeneous languages across a cluster or on a competitive choice of cloud platforms with dynamic provisio…

In my experience the costs of language agnosticism outweigh the benefits even without considering deployment. Good languages are general-purpose; a language that is drastically unsuited to some particular thing is probably not worth using at all, and if you're using a language that is decent at most things then the overhead of switching languages is higher than the benefit of using a language that gives a small advan…

a language that is drastically unsuited to some particular thing is probably not worth using at all

SQL and grep. Prolog and sed. Ruby and Rust. Yacc and Coq.

These are not small advantages. They are great yawning chasms of usability and functionality.

Re: Please do not attempt to simplify this code

#559

Post by dwild »

hibikir wrote: post #258
jml7c5 wrote: post #165

Earlier quoted context omitted.

As a novice programmer, I was absolutely stunned that this was not standard practice. A typical source file provides zero context, background on the subject, pointers to reference material/blog posts/books explaining the concepts, information on how it fits into the program's 'bigger picture', or (most importantly) the thought process that resulted in the file (i.e., why the choice was made to do _this_ rather than _…

There's plenty of good reasons to not write 95% of code with big walls of explanation. The first is a matter of cost: Writing a good explanation around everything is very expensive to do at first. A whole lot of the custom code you find in random companies, from the shiny SV startup to the old enterprise, is unimportant, cobbled together pieces. We have no idea of whether we are writing code that will be thrown away…

> We have no idea of whether we are writing code that will be thrown away in a week, a month, a year or whether it will last two decades.

Sometime also a code is meant to be temporary but is later deems to useful not to be used but no resource is allocated to is maintenance (in this case we could say refactoring). It's the case of many internal tools.

I remember when I did my first internship, I was in the configuration management team and I was responsible for doing the smoke test. I made some tools for myself to speedup the process and once my manager saw how useful they were, he was interested of giving them to the QA department. I refused because it broke every few builds and I knew after my internship I wouldn't be there to maintains them and it would just create more problems. There's so many instance where it wouldn't break so often or that person wasn't considering he would no longer be there to maintains it or won't have the time.

Re: Please do not attempt to simplify this code

#560

Post by dwild »

pas wrote: post #489
hibikir wrote: post #258

Earlier quoted context omitted.

There's plenty of good reasons to not write 95% of code with big walls of explanation. The first is a matter of cost: Writing a good explanation around everything is very expensive to do at first. A whole lot of the custom code you find in random companies, from the shiny SV startup to the old enterprise, is unimportant, cobbled together pieces. We have no idea of whether we are writing code that will be thrown away…

I vehemently disagree. Code without specification is a maintenance nightmare, a pure liability, a ticking time bomb. And sure, unless you're creating the control system of a nuclear reactor/warhead you don't have to go full Coq and CMMI5 and "high assurance" and whatnot, but spilling a few sentences as a minimal kind of pseudocode before writing what you want (a function, a class, a method, change the build system, r…

Personally I consider that if the code don't speak for itself, then it's most probably bad code, if it's not, add a comments explaining why it's not.

> spilling a few sentences as a minimal kind of pseudocode before writing what you want

Isn't it simply repeating the code you'll write? Which in the end, will be just as bad as the code alone or will lose time of the one that will read it afterward.

Sure it's hard to write good code, sure it's not always obvious what's bad code, but that's a big reason why the review process is there. It's not only to catch mistakes, it's also to see if someone else can understands what the code meant, the context, the decisions, etc... Sadly many just go quickly over it and just check for obvious mistakes.

Post reply on HN