July 21, 2017 at 8:30 am
Wonderful article, Steve. I've got decades of experience so I can relate to the author of the blog post and yourself.
I'm completely like you and the blog poster, the state of documentation has seriously deteriorated. This is the most important point in your article today. When I came to my current job within 6 months I was assigned to maintain 2 legacy systems. One project only has a users guide and the other didn't have any documentation at all. And this seems to be the norm with most of the software written here. I work in state government. It seems as though most people tend to write code with the intent of always being around to maintain it. To a degree this seems to be true, as a lot of people in state government jobs have been there for several years. I work with a much higher percentage of people who've been here for 20+ years than anyplace else I've ever worked. But newsflash people, you're not immortal. You will one day leave. Then some poor sap is going to have to try to figure out what in heck you were thinking.
Being in this field for a long time I also know the pressures that we work under. Most managers and customers aren't interested in comments in code. They want functioning software that does what they want done, normally as fast as possible. I'm not defending the lack of documentation and commented code, I'm just pointing out one of the biggest reasons why it happens.
Kindest Regards, Rod Connect with me on LinkedIn.
July 21, 2017 at 8:31 am
Excellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!
I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
July 21, 2017 at 8:37 am
mjh 45389 - Friday, July 21, 2017 6:11 AMfunbi - Friday, July 21, 2017 4:32 AMWait till you have to add === into the mix 😉Have you been using that nasty JavaScript? And there is also !==
The lack of any standards in programming languages is an irritation; having to switch between C and Python ( can catch myself out. Whilst I try and make my code legible by layout, meaningful identifiers and sometimes extra brackets for clarity I often find myself debugging others "horrible" code!
Javascript.. jQuery.. whatever the js flavour of the month is... :hehe:
We use Resharper here to keep the team in line, I will do anything to get rid of the orange lines and thankfully most of my fellow developers are OCD enough to do the same!
July 21, 2017 at 8:42 am
archie flockhart - Friday, July 21, 2017 5:28 AMnLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
I've also never seen a case for case insensitive 😀
It's not particularly hard to type the correct name in the proper case. SQL Server defaulting to case insensitive collations is hugely annoying to me.
July 21, 2017 at 9:00 am
ZZartin - Friday, July 21, 2017 8:42 AMarchie flockhart - Friday, July 21, 2017 5:28 AMnLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
I've also never seen a case for case insensitive 😀
It's not particularly hard to type the correct name in the proper case. SQL Server defaulting to case insensitive collations is hugely annoying to me.
I find database servers with the default of case insensitive switched to sensitive to be hugely annoying.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 21, 2017 at 9:28 am
n.ryan - Friday, July 21, 2017 4:34 AMAs for error handling: religious wars and arguments about the use of the comic sans typeface are right up there with error handling compared to exception handling. While my preference is that expected errors should be handled cleanly and neatly and everything else is, well, an exception, it really doesn't matter as long as it's documented well enough. This ties right in back to the point about the (lack of) documentation.
What I hate is when people try to do too much error handling, but do it poorly, and their code ends up swallowing or obfuscating the actual error that happened, making it harder to troubleshoot.
July 21, 2017 at 10:09 am
Chris Harshman - Friday, July 21, 2017 9:28 AMn.ryan - Friday, July 21, 2017 4:34 AMAs for error handling: religious wars and arguments about the use of the comic sans typeface are right up there with error handling compared to exception handling. While my preference is that expected errors should be handled cleanly and neatly and everything else is, well, an exception, it really doesn't matter as long as it's documented well enough. This ties right in back to the point about the (lack of) documentation.What I hate is when people try to do too much error handling, but do it poorly, and their code ends up swallowing or obfuscating the actual error that happened, making it harder to troubleshoot.
What's annoying is when different groups can't agree on what should be a hard error and what should be some kind of return message to be handled by the calling party. Working on a project now and several different groups of coders handle errors in spectrum from throw a hard error, some kind of error code in the returns, to success with all negative return values, to success with an obscure nested message indicating something might be wrong to simply success regardless of what happened :angry:
July 21, 2017 at 10:21 am
Can you imagine having to go thru all your SQL code and change = to == ... but only for comparisons and not for assignments?
LOL
July 21, 2017 at 11:34 am
ZZartin - Friday, July 21, 2017 8:42 AMarchie flockhart - Friday, July 21, 2017 5:28 AMnLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
I've also never seen a case for case insensitive 😀
...
You never discuss your code verbally?
If you have objects which differ only in case, you cannot coherently speak to another person about them; you have to pepper your statement with descriptors and qualifiers to ensure they know which specific case-sensitive thing you're referring to.
Now how about a developer who loses their ability to physically type and has to dictate their code. Can you imagine having to dictate, say, proper camelCase of every singleObject every single time you have to refer to it?
One of the things I do lament is the declining quality of documentation.
I wanted to be sure about something to do with PowerShell yesterday, so I searched Microsoft's documentation site for the PowerShell grammar. What did I find? A blog post from over a decade ago with the developer begrudgingly providing a draft grammar because so many people had asked for it (which raises the question of how the language got as far as it had at that point without a grammar...). This was a plain text dump, incomplete, and now out-of-date. And that was it.
July 21, 2017 at 12:12 pm
archie flockhart - Friday, July 21, 2017 5:28 AMLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
I agree. Case sensitive data is great, but not code.
It's only a minute, but in R, sum(x, NA.rm=TRUE) threw me. The NA needs to be na.
July 21, 2017 at 12:14 pm
chrisn-585491 - Friday, July 21, 2017 6:59 AMI agree with the original article writer on many issues, mainly because I've got 35 years of computer use under my belt. (That explains my waist line!)
belts, right? I know I've gone through a few over the years. 😛
July 21, 2017 at 12:16 pm
KGERBR - Friday, July 21, 2017 10:21 AMCan you imagine having to go thru all your SQL code and change = to == ... but only for comparisons and not for assignments?
LOL
No, but I'd love to have this being a refactoring point across a decade. Add == and in SQL Server 2028, remove = for comparisons.
July 21, 2017 at 2:13 pm
Steve Jones - SSC Editor - Friday, July 21, 2017 12:16 PMKGERBR - Friday, July 21, 2017 10:21 AMCan you imagine having to go thru all your SQL code and change = to == ... but only for comparisons and not for assignments?
LOL
No, but I'd love to have this being a refactoring point across a decade. Add == and in SQL Server 2028, remove = for comparisons.
== is just stupid, IMHO. In this day and age of all this talk about AI and machine learning, if the compiler can't figure out the difference between relational comparisons and assignments, then you might want to avoid the compiler.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 21, 2017 at 2:16 pm
Steve Jones - SSC Editor - Friday, July 21, 2017 12:12 PMarchie flockhart - Friday, July 21, 2017 5:28 AMLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
I agree. Case sensitive data is great, but not code.
It's only a minute, but in R, sum(x, NA.rm=TRUE) threw me. The NA needs to be na.
Case sensitive data is fine but only where you need it. Limit case sensitivity only to columns that absolutely need it.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 21, 2017 at 2:18 pm
KGERBR - Friday, July 21, 2017 10:21 AMCan you imagine having to go thru all your SQL code and change = to == ... but only for comparisons and not for assignments?
LOL
Nah clearly the answer is we should just switch all comparison operations over to powershell notation.
Viewing 15 posts - 16 through 30 (of 78 total)
You must be logged in to reply to this topic. Login to reply