April 25, 2022 at 12:00 am
Comments posted to this topic are about the item The Craziness of Code
April 25, 2022 at 2:14 pm
Inconsistencies are a result of not having adequately defined and enforced standards. The reasons for the lack of standards is varying. While some rationale is sensible or a reasonable byproduct of the speed in which things change, other rationale is absurd and proof positive of laziness and/or unqualified developers and then there's everything in between.
I've observed that nearly everyone is in favor of standards and consistency. I've also observed that nearly everyone insists that the standards be set according to their own patterns and standards. So technically, nearly every piece of code adheres to a standard, just not the same one.
Maybe we can all agree on the definition of oxymoron?
-
April 25, 2022 at 3:00 pm
I appreciate what you said, Jason. And the difficulties of standards in code writing, Steve. In all the years I've been writing code, I've only worked at one place that set a standard on coding style. Where I currently work there are some code bases that are decades old. So, in fairness to the men and women who wrote that stuff back in the day, their coding standards may have been agreed upon back then, but they moved on.
Also, sometimes the tools work against you. For example, when modifying my colleagues code try to follow their coding patterns. Sometimes that's easy, but other times Visual Studio re-writes it. For example, here's how I would write a simple function for adding two ints:
public int public int AddTwoInts(int a, int b)
{
return a + b;
}
and here's how my colleague likes to write it:
public int public int AddTwoInts(int a, int b) {
return a + b;
}I follow his pattern, but Visual Studio always puts it back the way I like it. My guess is there's some configuration in Visual Studio that's changing the code back the way I typically write it, but I don't know where that is. And I don't modify that colleague's code often, so I don't look it up. Still, it must be a pain for him when I've finished modifying his code. I do apologize for the opening brace being under the function's declaration.
Kindest Regards, Rod Connect with me on LinkedIn.
April 25, 2022 at 3:33 pm
I get less concerned over the formatting of code. These days we have products like SQL Prompt and other tools that can reformat things as we need them. I do like to see consistent styling with a Git Hook or something to ensure PRs and other things look the same, but I don't get too caught up in where the parents or braces are.
However, it's more that I see vastly different styles of how to solve problems. It seems that if we find a better way to do something, like use the OVER() for a running total, we rarely decide to refactor other code to look like this. Something we ought to do over time.
April 25, 2022 at 4:57 pm
I get less concerned over the formatting of code. These days we have products like SQL Prompt and other tools that can reformat things as we need them. I do like to see consistent styling with a Git Hook or something to ensure PRs and other things look the same, but I don't get too caught up in where the parents or braces are.
However, it's more that I see vastly different styles of how to solve problems. It seems that if we find a better way to do something, like use the OVER() for a running total, we rarely decide to refactor other code to look like this. Something we ought to do over time.
If it ain't broke - don't fix it. So what if the legacy code doesn't follow some newly defined standard - or use the latest functionality available? Unless that code is contributing to an issue then there is no reason to refactor the code just to be consistent with newer standards or functionality.
Is it worth the time and effort to refactor said code - if that code is performing within spec? If it isn't performing to spec - then it should be on the to-do list and that is when you can introduce new functionality to address the performance issues. If not, then leave it alone and don't worry about the style or the fact that it is using 'legacy' functionality. It works...it gets the job done - within the defined requirements.
Would it be nice to have all code refactored? Probably - but it just isn't worth the time and effort when that code works as designed.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
April 25, 2022 at 5:10 pm
I think the key words there are performance. If we've improved performance with an OVER(), then yes, we ought to refactor older code. If we've changed from an IF statement to a lambda of some sort, do we refactor? Maybe. I think you want to think about this, and find guidance for your team. Maybe more importantly, ensure that people ask questions if they don't know how code works. At that time, it might be worth it to refactor things, but only if you have tests around to ensure the refactor doesn't introduce new bugs, err features, into the app.
April 25, 2022 at 5:28 pm
If it ain't broke - don't fix it. So what if the legacy code doesn't follow some newly defined standard - or use the latest functionality available? Unless that code is contributing to an issue then there is no reason to refactor the code just to be consistent with newer standards or functionality.
Is it worth the time and effort to refactor said code - if that code is performing within spec? If it isn't performing to spec - then it should be on the to-do list and that is when you can introduce new functionality to address the performance issues. If not, then leave it alone and don't worry about the style or the fact that it is using 'legacy' functionality. It works...it gets the job done - within the defined requirements.
Would it be nice to have all code refactored? Probably - but it just isn't worth the time and effort when that code works as designed.
I agree in the sense that if a certain block of code is functioning and not introducing any performance or, most importantly, security risks, then there is no need to address it every time new standard definitions take form. At that point legacy code becomes a road block to new standards and techniques because its not feasible to address every line of code in every project every time a new standard or technique is introduced.
Refactoring legacy code should almost always wait until that block of code needs to be changed in some fashion as part of a project or an issue. It is then that code written using legacy patterns should be updated to whatever the latest standard is (earlier as time permits of course, this is just the point when it should no longer be optional).
In my experience this step is often not done for expedience sake and so the old legacy code gets the bare minimum update to make it continue to function but is left in its older state. It is work to refactor old code to new ways and the payoffs aren't always obvious so it tends to appear as though it's just work for the sake of elegance or to satisfy an architect's "unnecessary" attention to detail. Therefore it gets skipped and gives us the illusion of efficiency
IMHO the biggest reason to keep things consistent is that when we introduce consistency our muscle memory can kick in and that makes working with code, particularly during production issues, more efficient. The phrase, "Slow is smooth, smooth is fast" is a phrase from the Special Forces and is describing the benefits of muscle memory in execution. The more consistency the more muscle memory can be of benefit. During a production outage, that benefit usually pays for all of the added time and money spent on refactoring and keeping things as consistent as possible.
-
April 26, 2022 at 2:04 pm
I get less concerned over the formatting of code. These days we have products like SQL Prompt and other tools that can reformat things as we need them. I do like to see consistent styling with a Git Hook or something to ensure PRs and other things look the same, but I don't get too caught up in where the parents or braces are.
However, it's more that I see vastly different styles of how to solve problems. It seems that if we find a better way to do something, like use the OVER() for a running total, we rarely decide to refactor other code to look like this. Something we ought to do over time.
Git Hooks? I've never heard of Git Hooks. I continue to use Git in my personal development, but I doubt that I'd need Git Hooks, if I'm the only one working on a project. Nevertheless, Git Hooks is something I want to investigate. It will be useful in the future.
Kindest Regards, Rod Connect with me on LinkedIn.
April 26, 2022 at 2:48 pm
I like your approach, Jason. I agree with you that not every legacy project needs to be refactored, just for refactoring's sake. If it works, it is secure and I'll add easily maintainable, then leave it alone. However, I've begun to loath the phrase "if it ain't broke, don't fix it". What I'm witnessing is that phrase pushed to its extreme. There's no incentive to improve anything. Consequently, technical debt is getting so high that as a result people become afraid of touching any code. That results in some weird ways of avoiding editing the code. Things like putting files into the wrong places (i.e.: system folders) just because someone discovered that if you put a file in a system folder, with just the right formatting, then the application works, etc. That ain't right.
Another result I've seen of taking "if it ain't broke, don't fix it" to extremes is people's reluctance to improve themselves by learning how to do anything new. Again, for example, just about all of the .NET applications written here are written using .NET Framework 4.5.2. A year ago, I told my colleagues that .NET Framework 4.5.2 was going out of support this year. Nothing happened because that would mean upgrading apps, adopting newer versions of Visual Studio, etc. (And not even using the current version of Visual Studio, just newer than what they used 10 years ago.) Yesterday I reminded them that Microsoft's support of .NET Framework 4.5.2 is ending, today. I think it's causing some minor panic, because now we've got to upgrade apps that no one wanted to for a year. .NET 4.5.2 going out of support doesn't mean that all apps suddenly fail, or servers burst into flames. But it does mean that as time goes back, those apps will become less secure, because Microsoft "...will no longer provide updates including security fixes."
I'll end by saying that just because a system isn't broken, that doesn't imply that it cannot be improved.
Kindest Regards, Rod Connect with me on LinkedIn.
April 28, 2022 at 10:49 am
Rod, take a look at a package called pre-commit. The idea is that when you attempt to commit code to git it will run a whole bunch of checks.
Each type of check is a "hook". There's loads of them to choose from such as SQLFluff.
For Python programming I have various linters, formatters and code checkers and also one for git markdown files. It takes away almost any unproductive debate about code formatting.
I don't set it to act on the commit as I prefer to run it manually at frequent intervals.
April 28, 2022 at 11:03 am
I've found HR policies cause problems that people work around and in doing so get the organisational equivalent of tech debt.
The bureaucracy involved in promoting a junior to senior is horrendous. So much so that it is easier to recruit a senior in the 1st place. Then you have too many seniors in a team all wanting to act like they are THE senior.
I've seen a project fail due to ludicrous complexity. 2 years down the pan for something that, when outsourced, became a few PHP files and a MySql database. No ESB, MS Dynamics, no fancy frameworks, no EDW design by asylum inmates.
I've seen fairly basic (from a business point of view) systems being rewritten over and over again for no tangible business benefit simply because each predecessor switched out a different 10% of the bugs and used tech debt as a sort of bug balm.
Refactor, cover with automated tests, increase testing until you can tell what the damn thing is trying to do by reading the test suite but avoid a rewrite like the plague.
April 28, 2022 at 2:54 pm
Rod, take a look at a package called pre-commit. The idea is that when you attempt to commit code to git it will run a whole bunch of checks.
Each type of check is a "hook". There's loads of them to choose from such as SQLFluff.
For Python programming I have various linters, formatters and code checkers and also one for git markdown files. It takes away almost any unproductive debate about code formatting.
I don't set it to act on the commit as I prefer to run it manually at frequent intervals.
David, thank you for letting me know about this! There is so much about Git that, even after working with it for 5 years, I am still learning more. I LOVE it!!
I went into the .git/hooks directory in one of my local repos to see what was there. I saw about a dozen .sample files, all for Bash. I'm sure I don't have Bash on my Windows machine. (I'm sure I could technically get it, but I doubt I have the dish space to install it.) I'm wondering if I should get some PowerShell .sample files instead? Or perhaps I'm still not understanding hooks?
Kindest Regards, Rod Connect with me on LinkedIn.
April 28, 2022 at 3:37 pm
You can use PoSh (https://www.visualstudiogeeks.com/DevOps/UsingPowerShellForGitHooksWithVstsGitOnWindows). You could also use batch files (https://stackoverflow.com/questions/49032756/git-hooks-on-windows-with-batch).
These technically start with bash as the way git works is to be cross-platform, so bash is installed. Actually, I believe git installs git-bash, with just a basic set of ported bash commands on your system that invoke a shell. Windows-Bash, or the Linux subsystem (WSL), isn't too large, AFAIK. I think the basic v1 versions were a few GB. The newer V2 is larger.
April 28, 2022 at 8:16 pm
The pre-commit hooks can be any language. Quite a few of them can be just YAML in the . pre-commit-config.yaml file.
https://github.com/pre-commit/pre-commit-hooks.
In the 1st example shown in the link above you can add as many lines beginning - id: as you have hooks you want to implement.
-. id: check-json
-. id: check-xml
-. id: check-yaml
April 28, 2022 at 10:15 pm
I REALLY enjoyed the "Programming Sucks" article you provided a link to, Steve. The funniest part about it is that it's all true! 😀
Shifting gears a bit, thank you for what you do!
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply