This is all Golang is good for.
Please do not attempt to simplify this code
491–500 of 647 posts
Re: Please do not attempt to simplify this code
#492Kubernetes, eh? (strikes through its name on my list)
Why? Does this file/comment cause you to lose confidence in the project in some way? I'm genuinely curious to understand the reason for your comment.
Have you ever tried to refactor code like this? They're not going to. Whatever was written is as good as it will ever get.
Note that while this isn't good practice I still would adopt Kubernetes. I was exaggerating for effect.
Re: Please do not attempt to simplify this code
#493The key thing about complexity is that, you can move it around, but you can't make it go away.
The complexity has to be there, somehow. It's also highly subjective how one sees and grasps complexity.
Breaking code up for the purpose of reducing complexity is more often a symptom of clearing your mental space.
But IMO most often, complex code is much more well off being put in the same place, and with extensive comments too.
I also believe it's a true flaw to believe that a lot of comments are unnecessary when writing "important" code.
Comments are written in a human language, we interpret them as such. Computer language is different and it takes, more often than not, more mental power to understand and more important to change.
Re: Please do not attempt to simplify this code
#494Having spent 25+ years writing, viewing, commenting on and reviewing code in a multitude of languages, this is good stuff to see - regardless of the 'style' of programming (or the language broadly-speaking). Stepping back and whilst we can all overlook it, good code comments can make an enormous difference in productivity - both for an individual, a team and indeed a business. It aids repository knowledge (something…
> There are those that believe good code shouldn't need explanation and to some degree that's true, but you can't apply that brush to every codebase. Code can become complex, awkward, spaghetti-like and almost unfathomable at times. I have yet to find a codebase that couldn't be made clear as soon as a programmer actually put some effort into doing so. Far too often adding a comment is used as an excuse to give up on…
Here’s a great practice:
1. Write some piece of code
2. Now write a comment about it
3. Is the comment adding more information, making the code more clear?
If Yes: Put that information into the code. Rename variables. Pull out code into subroutines.
If No: Delete the comment.
You’ll be amazed at how often this practice works. Doing it all the time will make your code more readable.
We have a second, enforced practice at work, thanks to code review. The question in your head is simply: “Am I gonna get a comment about this at review time?” If yes, you gotta make the code clearer/simpler/better. Because you’ll have to answer and address the comment, and that’s just gonna slow you down more than if you just fix the problem now.
Re: Please do not attempt to simplify this code
#495Earlier quoted context omitted.
Abstractions don't remove complexity. Abstractions instead hide the appearance of complexity behind layers of ever increasing code.
I believe that premature abstraction is terrible. But in some cases good abstractions may help with handling complexity and may make testing easier. I have a feeling that because authors say that this class should not be changed / refactored, they failed to introduce a good abstraction. This also implies that their tests are inadequate.
I agree with the direction of your opinion, but would say it isn't a matter of helpfulness. In some cases is it is a necessity.
It must be understood that complexity is an economic consideration and not either a financial or technology consideration. It is always already present. Complexity is not something that is created or destroy; but retained, absorbed, or transferred.
Abstractions become necessary when they separate different functional layers to perform different respective responsibilities. In this case complexity is transferred both in and out of a system at a given layer, but you don't care so long as you aren't doing the jobs of the other layers. That is referred to as separation of concerns which results in the hardening of a system (risk reduction) which is the side effect of reducing costs due to restricting requirements available.
Many abstractions exist solely to provide a layer of convenience. In the case where an abstraction does the same job as the code it abstracts risks increase and costs increase. This is because the system continues to simultaneously absorb and transfer complexity like described above, but the requirements between the various layers isn't clearly separated. That results in fulfilling requirements, the same requirements, simultaneously at various layers. This has various names like scope creep, technical debt, and so forth. This is bad because risks and costs increase directly to the correlation of increased code and increased requirements. This is what makes the law of leaky abstractions valid.
It is easy to tell the difference between a necessary abstraction and a wasteful abstraction by the forcefulness of separation. If you can perform the same job in a lower level the abstraction isn't necessary and you are probably better off without it. Most JavaScript frameworks are unnecessary abstractions.
Re: Please do not attempt to simplify this code
#496Earlier quoted context omitted.
> There are those that believe good code shouldn't need explanation and to some degree that's true, but you can't apply that brush to every codebase. Code can become complex, awkward, spaghetti-like and almost unfathomable at times. I have yet to find a codebase that couldn't be made clear as soon as a programmer actually put some effort into doing so. Far too often adding a comment is used as an excuse to give up on…
Here’s a great practice: 1. Write some piece of code 2. Now write a comment about it 3. Is the comment adding more information, making the code more clear? If Yes: Put that information into the code. Rename variables. Pull out code into subroutines. If No: Delete the comment. You’ll be amazed at how often this practice works. Doing it all the time will make your code more readable. We have a second, enforced practice…
If that works for you then great, but I don't see the value in adding the comment only to remove it one way or another a moment later. What I do is 1. write some code 2. is code clear enough? If yes, stop. 3. clarify the code 4. goto 2.
Re: Please do not attempt to simplify this code
#497Earlier 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…
> This is not to say that there aren't reasons to write large comment blocks, or architecture documents, but that they are often better written not while the system is being first built, but later, in a maintenance cycle, when someone already had wished for the comments, and has regained the knowledge the hard way. I don't think the "Lean Manufacturing" approach works here. By the time someone "pulls" you for a comme…
Commit logs are also cheap to write, and it's easier for people to realize that whatever you read in "$vcs log" or "$vcs blame" might be severely outdated.
Re: Please do not attempt to simplify this code
#498The hubris in some of these comments is staggering. No, you wouldn't have more cleanly (and successfully) written this in $BETTER_LANGUAGE, even with your super power of perfect hindsight.
Re: Please do not attempt to simplify this code
#499Earlier quoted context omitted.
IDE or not, jumping around between functions amd their callers to understand a process is annoying.
Sure. In sane code the name of the function should describe what they do well enough that you rarely have to click in to learn how they do it. Or something like that...
I have read an extreme counter-opinion in some J or APL article. It said that it is a bad pactice to name small and common functions:
The example was maybe the average function - and the reasoning was, if I recall correctly:
1. The defintion is shorter then the name average ;)
2. Every praticioning programmer will recognise the definition as a common idiom
3. From the definition it is immediately clear how corner cases are handled (e.g. zero length array)
I just leave this here as an example to show, that programming communities/cultures exists with completely different/alien? ideas about what clean code is ;)
Re: Please do not attempt to simplify this code
#500Earlier quoted context omitted.
I don’t think this changes the inherent complexity of the code right? The basic logic of what is being done is still the same. De-indenting code but still having the same complexity, some of which is now abstracted by the language is still complexity. Maybe it somewhat helps the humans reading the code? But don’t you still have to reason about the basic state changes of the system the same way?
the code itself has the same complexity, but you are pushing the workload to the compiler, not to the human. Given the two options I typically prefer the compiler.
Compilers can only tell if programs are internally consistent, they can't help ensure that they are correct. Compilers don't know about inputs. Compilers don't know if the branch you wrote goes in the correct direction for a given input.