How to make simple code complicated
-
Super Lloyd wrote:
And there is much much more of it... :((
apart from adding layers of "really useful" stuff another favorite weenie passtime is implementing the very latest language features regardless if it makes sense useful or not. Even if doing so they manage not to not break the code they do ensure it becomes incompatible with people using older versions of the dev platform. shitloads of unmoderated stuff on github is constantly "updated" to use the very latest features of c# (or whatever language), and it's just too bloody bad for people using that if they are still on vs2015 or earlier. like idiot kiddies that feel a strong need to mount a wing on their car, 75% of the time it does nothing because their POS car is too useless to have it matter, and 24.9% of the time it'll actually reduce / retard safety and performance. my rules for using open/other peoples code/source/hell other peoples anything: - always copy and use local version only. (reference/acknowledge the origin in comments only) - if/when possible/time replace it with own code ... (other peoples code is always shit.) - only ever update if there is a very strong reason ... (small problems fix it yourself). - don't use just because it's there and looks cool. ... (today's cool is tomorrows dog vomit.) Why? Well delivering applications, packages and even complete systems to clients: - stability is 1,000 times more important than being the latest thing out there. ... and that saves me a shitload of 3AM Friday night headaches I don't need
Message Signature (Click to edit ->)
-
I see two reasons to make the
MustDologic its own function: #1: It is used in more than one place (not visible in the example). #2: Separating it improves the clarity of the logic in its original location. My worst tendency in the code I write is to let individual functions get large. Logic can become nested too deeply and the code can run over several screenfuls. As I debug, I will then have to refactor and move nested bits and pieces into their own functions just to make the overall thing clearer. If the development pace is a little slower, I'll do the refactoring as I write.Software Zen:
delete this;I try to put discrete code into its own method where it makes sense, even if the code isn't called anywhere else. In the event that the code is specific to a class, and not called from anyplace else in the app, I make it
privateorprotected(depending on its purpose). This pretty much keeps most methods to less than 50-100 lines.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I try to put discrete code into its own method where it makes sense, even if the code isn't called anywhere else. In the event that the code is specific to a class, and not called from anyplace else in the app, I make it
privateorprotected(depending on its purpose). This pretty much keeps most methods to less than 50-100 lines.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013The key for me is knowing when to stop. I had a coworker who was manic about writing his code in an OOP fashion. If he had a function with more than two control constructs (
if,for,while), he would often split it into multiple functions. While this may have been appropriate from an OOP-purist point of view, it could make logic and flow difficult to follow. It also made for a polluted name space. His names were good, but the fact that there was a name for something that was just anifstatement obscured the significance of the function.Software Zen:
delete this; -
Super Lloyd wrote:
And there is much much more of it... :((
apart from adding layers of "really useful" stuff another favorite weenie passtime is implementing the very latest language features regardless if it makes sense useful or not. Even if doing so they manage not to not break the code they do ensure it becomes incompatible with people using older versions of the dev platform. shitloads of unmoderated stuff on github is constantly "updated" to use the very latest features of c# (or whatever language), and it's just too bloody bad for people using that if they are still on vs2015 or earlier. like idiot kiddies that feel a strong need to mount a wing on their car, 75% of the time it does nothing because their POS car is too useless to have it matter, and 24.9% of the time it'll actually reduce / retard safety and performance. my rules for using open/other peoples code/source/hell other peoples anything: - always copy and use local version only. (reference/acknowledge the origin in comments only) - if/when possible/time replace it with own code ... (other peoples code is always shit.) - only ever update if there is a very strong reason ... (small problems fix it yourself). - don't use just because it's there and looks cool. ... (today's cool is tomorrows dog vomit.) Why? Well delivering applications, packages and even complete systems to clients: - stability is 1,000 times more important than being the latest thing out there. ... and that saves me a shitload of 3AM Friday night headaches I don't need
Message Signature (Click to edit ->)
I have noticed that most of those wings go on front-wheel drive cars and a wing on the rear end doesn't help those a whole lot and they don't help any car at lower speeds ie., the vast majority of driving. This reinforces your point even more - the added accessories might look nice but are of very little real value.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I see two reasons to make the
MustDologic its own function: #1: It is used in more than one place (not visible in the example). #2: Separating it improves the clarity of the logic in its original location. My worst tendency in the code I write is to let individual functions get large. Logic can become nested too deeply and the code can run over several screenfuls. As I debug, I will then have to refactor and move nested bits and pieces into their own functions just to make the overall thing clearer. If the development pace is a little slower, I'll do the refactoring as I write.Software Zen:
delete this;It can also make testing easier with more separation. Logic embedded in a loop can sometimes be tricky to test on single items. You might be able to make very small lists but not always.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I try to put discrete code into its own method where it makes sense, even if the code isn't called anywhere else. In the event that the code is specific to a class, and not called from anyplace else in the app, I make it
privateorprotected(depending on its purpose). This pretty much keeps most methods to less than 50-100 lines.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Using access modifier
internalis another way to be sure your method is never used outside of the assembly. For instance, I use it in static extension classes where I want to use an extension method anywhere in the library solution, but I don't want folks who use the library to have access to it. -
Super Lloyd wrote:
And there is much much more of it... :((
apart from adding layers of "really useful" stuff another favorite weenie passtime is implementing the very latest language features regardless if it makes sense useful or not. Even if doing so they manage not to not break the code they do ensure it becomes incompatible with people using older versions of the dev platform. shitloads of unmoderated stuff on github is constantly "updated" to use the very latest features of c# (or whatever language), and it's just too bloody bad for people using that if they are still on vs2015 or earlier. like idiot kiddies that feel a strong need to mount a wing on their car, 75% of the time it does nothing because their POS car is too useless to have it matter, and 24.9% of the time it'll actually reduce / retard safety and performance. my rules for using open/other peoples code/source/hell other peoples anything: - always copy and use local version only. (reference/acknowledge the origin in comments only) - if/when possible/time replace it with own code ... (other peoples code is always shit.) - only ever update if there is a very strong reason ... (small problems fix it yourself). - don't use just because it's there and looks cool. ... (today's cool is tomorrows dog vomit.) Why? Well delivering applications, packages and even complete systems to clients: - stability is 1,000 times more important than being the latest thing out there. ... and that saves me a shitload of 3AM Friday night headaches I don't need
Message Signature (Click to edit ->)
Come to the C++ world and really experience the love. Some 'post-modern' C++ doesn't even look like C++, because it sort of isn't. It's really Templates with C.
Explorans limites defectum
-
At first glance real application (new) code from someone else always looks complicated, and one has to work with it for a while to find it, eventually, simpler. And sometimes I wonder if with old age and worst memory I suffer from that more. Yesterday I mentioned some code looks excessively complicated for no reason, i.e. it does very simple task, and I got an incredulous look from a fellow developer... Maybe I was wrong? First I am always confused by the double layer of obfuscation where getting something from the db goes through 2 pass-through layers, each hidden behind their own interface, that return "data model". Thanks god for
Go To implementationand also sometimes some property are not named like the columns, or swapped around, tricky... I guess I am getting old here.. But then I stumbled on that (code simplified for sake of "clarity")! And I knew I was right, it's not just me, code was complicated! void DoSomething() { foreach (var d in Data) { if (MustDo(d.Code)) { // do it! } } } bool MustDo(string code) { if (BigCondition) { return GetData(code)?.Should ?? false; } return false; } AData GetData(string code) => Data.FirstOrDefault(x => x.Code == code); clearly this is over complicated and can be rewritten void DoSomething() { foreach (var d in Data) { if (BigCondition && d.Should) { // do it! } } } And there is much much more of it... :(( Well I guess that's why they pay me! :laugh: :^)A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I recently replaced two nested loops with index arithmetic with a single function call. I even have a theory of why this old code was in place, but I feel still dumbfounded by spending several minutes deciphering what the code is supposed to do while, really, a single call to a single well-documented function would have done the job.
-
At first glance real application (new) code from someone else always looks complicated, and one has to work with it for a while to find it, eventually, simpler. And sometimes I wonder if with old age and worst memory I suffer from that more. Yesterday I mentioned some code looks excessively complicated for no reason, i.e. it does very simple task, and I got an incredulous look from a fellow developer... Maybe I was wrong? First I am always confused by the double layer of obfuscation where getting something from the db goes through 2 pass-through layers, each hidden behind their own interface, that return "data model". Thanks god for
Go To implementationand also sometimes some property are not named like the columns, or swapped around, tricky... I guess I am getting old here.. But then I stumbled on that (code simplified for sake of "clarity")! And I knew I was right, it's not just me, code was complicated! void DoSomething() { foreach (var d in Data) { if (MustDo(d.Code)) { // do it! } } } bool MustDo(string code) { if (BigCondition) { return GetData(code)?.Should ?? false; } return false; } AData GetData(string code) => Data.FirstOrDefault(x => x.Code == code); clearly this is over complicated and can be rewritten void DoSomething() { foreach (var d in Data) { if (BigCondition && d.Should) { // do it! } } } And there is much much more of it... :(( Well I guess that's why they pay me! :laugh: :^)A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Each code contains at least a useless line and a wrong one. So... do { Remove(code.WrongLine); } until (code.NumberOfLines == 1) You obtain a code with a single line: a useless and probably wrong line.
-
At first glance real application (new) code from someone else always looks complicated, and one has to work with it for a while to find it, eventually, simpler. And sometimes I wonder if with old age and worst memory I suffer from that more. Yesterday I mentioned some code looks excessively complicated for no reason, i.e. it does very simple task, and I got an incredulous look from a fellow developer... Maybe I was wrong? First I am always confused by the double layer of obfuscation where getting something from the db goes through 2 pass-through layers, each hidden behind their own interface, that return "data model". Thanks god for
Go To implementationand also sometimes some property are not named like the columns, or swapped around, tricky... I guess I am getting old here.. But then I stumbled on that (code simplified for sake of "clarity")! And I knew I was right, it's not just me, code was complicated! void DoSomething() { foreach (var d in Data) { if (MustDo(d.Code)) { // do it! } } } bool MustDo(string code) { if (BigCondition) { return GetData(code)?.Should ?? false; } return false; } AData GetData(string code) => Data.FirstOrDefault(x => x.Code == code); clearly this is over complicated and can be rewritten void DoSomething() { foreach (var d in Data) { if (BigCondition && d.Should) { // do it! } } } And there is much much more of it... :(( Well I guess that's why they pay me! :laugh: :^)A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
We all admit that this happens, but we never stop to think about why it happens. Let me put forth a hypothesis - deadlineitis! Programmers have been bamboozled into believing that software development should be an engineering discipline. While there are some things that engineering can offer to software development, there is much that the engineering discipline cannot "solve" for software development. Let me defend this. "Engineering" is the discipline that says we can build massive structures by applying known smaller structures, that have mathematical descriptions which can be added together to present a mathematical model of the desired structure. In software development, so-called "software engineers" repeatedly encounter instances of where there is NO smaller software structure - merely methods that "almost" work, methods which are "not quite" what is required, or even a lack of smaller structures that even come close to what is required. Add to this that combining all these "iffy" structures together leads to coupling problems - emergent behavior unanticipated by anybody. (And if you are looking for mathematical precision, well, good luck with that.) So software development winds up being a series of "experiments" - tweaking prior structures, and even developing your own structures, with the "requirements" for the structures being imprecise and unclear. Under "project management", this is seldom, if ever, accounted for, because, like so much other stuff, the concept of "project management" was imported into the domain of software development from the engineering disciplines. Imagine, if you will, the plight of an bridge engineer if he had to redefine what a "truss" was multiple times during the life of the project. It's relatively easy to put together a bunch of well-known structures to complete a much larger structure on time, on budget, and safe (yet even then we have major cost overruns and major delays, and even failures of the final product). The problem with software is the fact that compared to "physical" products, there is no conceptual limit to what an individual piece of software might be. You want it to do A, B and C. Why not? Could you get it to do D as well? No problem. How about E and F? Well, that may strain our resources a bit. Oh, we can't have that. How about if we eliminate C and D - could we get E and F for the same cost and in the same time? And on and on it goes. So what happens when a software developer has to develop on of these base widgets, or t
-
At first glance real application (new) code from someone else always looks complicated, and one has to work with it for a while to find it, eventually, simpler. And sometimes I wonder if with old age and worst memory I suffer from that more. Yesterday I mentioned some code looks excessively complicated for no reason, i.e. it does very simple task, and I got an incredulous look from a fellow developer... Maybe I was wrong? First I am always confused by the double layer of obfuscation where getting something from the db goes through 2 pass-through layers, each hidden behind their own interface, that return "data model". Thanks god for
Go To implementationand also sometimes some property are not named like the columns, or swapped around, tricky... I guess I am getting old here.. But then I stumbled on that (code simplified for sake of "clarity")! And I knew I was right, it's not just me, code was complicated! void DoSomething() { foreach (var d in Data) { if (MustDo(d.Code)) { // do it! } } } bool MustDo(string code) { if (BigCondition) { return GetData(code)?.Should ?? false; } return false; } AData GetData(string code) => Data.FirstOrDefault(x => x.Code == code); clearly this is over complicated and can be rewritten void DoSomething() { foreach (var d in Data) { if (BigCondition && d.Should) { // do it! } } } And there is much much more of it... :(( Well I guess that's why they pay me! :laugh: :^)A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
And I knew I was right, it's not just me, code was complicated!
If the idiom was consistent then there probably was a reason. Some reasonable possibilities for indirection (which might not apply in your case) - Unit testing mocking - Insuring that the current db code does not leak into other layers.
