- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
No, no, no, no, no, no. Purge the evil from among your codebase.
If you leave it there, then one day someone will have a problem, find this code, and the frist thing they'll say is "That can't be right. Some fool named GRH commented out the code and then forgot to reinstate it."
Admin
For shame, GRH!
To be clear, without the commented out lines, the last part of the function is this:
Admin
Smart move to keep these plain text passwords in the code base, GRH! What can be more secure?
Admin
Yeap. But I have seen people say it's easier (WTF???) to see commented out code in the file than to just go back in version control. Same with people who insist on having changelogs in the code because you don't have to look into version control to see who changed what.
Admin
In my experience, those people are also ones who learned programming before version control was a thing. You never delete; Only comment it out. Because learning how to search the history is harder than just reading the comments.
Admin
The problem is that when code is deleted, you don't know there used to be something there, so you wouldn't even know to run blame on that block of code to see who removed it.
A compromise could be to replace it all with a comment saying "Removed a bunch of useless code here".
Admin
That is of course under the assumption there is such a thing as a changelog. Haven't seen one here yet.
Admin
Sometimes I do see the benefit of the change log (in stored procedures for example it's MUCH easier to see a comment up top what was changed than dig through version control) but a lot of times it's just an excuse to keep old code "in case we need it"
Admin
To which the answer is "well, if we need it, we'll dig it out of the old versions in version control."
Admin
I used to think this might be the case, but I see as many young programmers do this as experienced ones.
I know a guy that actively resists this change even when I show him that although it's faster to see a change by looking at the code and seeing the old version, it's far easier to see what has changed by using the diff tool in source control. Often, the line has a subtle change, and commenting out the old one and adding a new one diffs like an addition of code, giving no comparison at all. Changing the line allows the diff tool to point out the exact difference.
So, since this affects the rest of the team supporting his code changes, he is not permitted to override team decisions "because it's easier for him".
Admin
Does your source control tool not have an equivalent of SubVersion's "blame" feature where is displays an annotated version of the file in a special viewer that makes it much easier to see who changed what and when than actually reading through a list of comments that are "probably correct"?
Admin
Actually it's either ".net framework" or ".net core" - actually now it's just ".net". IK, the naming is nearly as bad with Java's editions, even though MS had the golden opportunity to stick with "netcore" but they really wanted to hammer down that mono got fully integrated with ".net 5" - which itself is funny, because there was no ".net 4" so that there is no confusion with ".net framework 4.x" - after a lot of developers got confused by ".net standard".
Admin
I don't blame them. .Net Standard has versions 2.0 and 2.1. It turns out that almost nobody should use 2.1 because the only classic framework version it's compatible with is 4.8.1, but 4.8.1 doesn't run on anything but the newest platforms. So, if you want cross .NET Core/.Net Framework compatibility, the newest version you can use to target all supported installs of both is .Net Standard 2.0.
Admin
"teh database" FTW!
Admin
In code or in config files, still in plain text.
Admin
Oh yeah, don't get me wrong, it was by no means my intention to excuse MS naming disaster. Framework should be dead for years now, but similar to Sun MS is super afraid to loose those "enterprise" customers that still run their stuff on pretty much ancient tech right now - so they keep it on live support. Standard was kinda the promise that framework is still alive and doing well, but obviously even with 2.1 it was a very limited experience. So honestly it would be better to actually put out a definitive deadline and let it die. Then at least customers get a reason to act (if all those numerous security issues they don't care were not enough by now).
Admin
Out one side of their mouth they are saying that Framework is dead. Out of the other side, .NET 8, the current long term support release of Core, goes out of support in just over two years while .Net Framework 4.8 has no defined end of life yet and a support commitment until at least 2028.
.NET Core updates pretty much always introduce some sort of issue. 6-to-8 introduced issues with triggers on databases - as in, if your tables have a trigger, but you don't "tell the framework about it", SELECTs don't even work.
So, between the stability of Framework, instability of Core, and the support dates, a clear message is being sent for conservative users to use Framework.
Our team switched to writing new code in Core a while back. This month, we're updating ten projects from .NET 6 to .NET 8. Due to the corporate tendencies to hand test everything and to have connectivity to a ton of different things, testing is an absolute nightmare. I told them to invest heavily in automated testing while writing the .NET 6 stuff, but that fell on deaf ears.
Personally, I feel that unit tests make my development faster. However, most of my coworkers have been avoiding it for 20 years "because it's unnecessary complication". Now that automated unit testing, along with decent test automation at the deployed software level in the test environment, would make these upgrade dead simple, they see the fast pace of Core as essentially a 10% tax on development. Either put in more time writing tests up front, or do another every-other-year test cycle for the version upgrade.
I see it as a 10% tax on not learning new skills ten years ago. But, whatever, that's Corporate America. They are not ready for the upgrade treadmill.
Admin
Wasn't this code on a "zip file on a shared drive" ? That doesn't promise much version control.
Admin
YEEEEEE-HAWWWWWWWWWW!!!