I'm a-feared
-
Comment of the day, probably from the same guy whom I've written about before.
//This lock probably isn't needed but it's here because of fear.
And while we're at it.
//Loop until a thread opens up
while (completedTheadIds.Count == 0) { }:sigh: Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
while (completedTheadIds.Count == 0) { }
Um.... um... um........ :omg: In all fairness, I assume the coder at least made it a point to keep that above zero somehow? Maybe??
Jeremy Falcon
-
Well-written and properly documented code can be refactored a little at a time without endangering reliability. Poorly written code really needs to be refactored, but really can't be because that same code probably doesn't have any comments, supporting technical documentation, and/or documented requirements.
".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, 2013In the '80s, a friend of mine was doing a Summer co-op rotation at a company that used COBOL for their inventory control system. The application created a report that showed 'x' count of fully assembled units, 'y' count of subassemblies, etc... The printout of the code was about 2 feet high; he was tasked with finding the errors and fixing them. As he went through the code, he found variables had been reused for various purposes. When he brought that to the managers attention, they decided they'd been running the plant with the existing code and had managed, so... it didn't need to be modified.
-
Well-written and properly documented code can be refactored a little at a time without endangering reliability. Poorly written code really needs to be refactored, but really can't be because that same code probably doesn't have any comments, supporting technical documentation, and/or documented requirements.
".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, 2013John Simmons / outlaw programmer wrote:
Poorly written code really needs to be refactored, but really can't be because that same code probably doesn't have any comments, supporting technical documentation, and/or documented requirements.
Indeed, yet that's most of the code I've come across. Now are you too afraid to touch code like that even when it's necessary? Because I know people who are. I've met a developer who was afraid to throw away some code that was never reached, something like
if (false) { ... }(maybe some test code once?) because "what if that code DOES do something?" What the hell, that code never did, never does and never will do anything so just friggin delete it already! And here's a real gem, "I'm not sure if this code, that is in source control, is used so I'm going to comment out this block instead of deleting it completely (and I mean committing it like that)." What the hell do you even know how code works!? I agree that some code SHOULD not be touched because the chances of it breaking are far to big. However, ultimately not being able to find out what some code does or even not daring to change it after you've found out is just an indication of not knowing what the hell you're doing.Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
In the '80s, a friend of mine was doing a Summer co-op rotation at a company that used COBOL for their inventory control system. The application created a report that showed 'x' count of fully assembled units, 'y' count of subassemblies, etc... The printout of the code was about 2 feet high; he was tasked with finding the errors and fixing them. As he went through the code, he found variables had been reused for various purposes. When he brought that to the managers attention, they decided they'd been running the plant with the existing code and had managed, so... it didn't need to be modified.
I once worked on an application that just had a class Globals with public variables like ProductName, and whenever anything somewhere needed a ProductName it would use Globals.ProductName. Imagine my initial surprise when I made a change to some form (WinForm) and a completely other, unrelated form broke X| How the hell do people even come up with such shit? :~
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
Marc Clifton wrote:
while (completedTheadIds.Count == 0) { }
Um.... um... um........ :omg: In all fairness, I assume the coder at least made it a point to keep that above zero somehow? Maybe??
Jeremy Falcon
Jeremy Falcon wrote:
In all fairness, I assume the coder at least made it a point to keep that above zero somehow?
Not that I can tell. The whole threading implementation looks like a disaster. The program would probably run faster as a single threaded app. Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Jeremy Falcon wrote:
In all fairness, I assume the coder at least made it a point to keep that above zero somehow?
Not that I can tell. The whole threading implementation looks like a disaster. The program would probably run faster as a single threaded app. Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
It should be reimplemented in JavaScript. ;)
Jeremy Falcon
-
It should be reimplemented in JavaScript. ;)
Jeremy Falcon
Jeremy Falcon wrote:
It should be reimplemented in JavaScript.
From the way the code is written (methods beginning with a lowercase letter, use of string values "0" and "1" for booleans) I think the programmers were actually Javascript coders. X| Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Jeremy Falcon wrote:
It should be reimplemented in JavaScript.
From the way the code is written (methods beginning with a lowercase letter, use of string values "0" and "1" for booleans) I think the programmers were actually Javascript coders. X| Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Well, if they were expert JavaScript coders, their string booleans should've been in single quotes. :rolleyes: :-D
Jeremy Falcon
-
Comment of the day, probably from the same guy whom I've written about before.
//This lock probably isn't needed but it's here because of fear.
And while we're at it.
//Loop until a thread opens up
while (completedTheadIds.Count == 0) { }:sigh: Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Found a similar comment:
// That should not happen
if (!someDictionary.ContainsKey(otherIndex))
{
return;
}You see: if it happens nonetheless, just leave the 100 lines function, no exception thrown, also no warning logged, just get away...
-
Well-written and properly documented code can be refactored a little at a time without endangering reliability. Poorly written code really needs to be refactored, but really can't be because that same code probably doesn't have any comments, supporting technical documentation, and/or documented requirements.
".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 -
John Simmons / outlaw programmer wrote:
Poorly written code really needs to be refactored, but really can't be because that same code probably doesn't have any comments, supporting technical documentation, and/or documented requirements.
Indeed, yet that's most of the code I've come across. Now are you too afraid to touch code like that even when it's necessary? Because I know people who are. I've met a developer who was afraid to throw away some code that was never reached, something like
if (false) { ... }(maybe some test code once?) because "what if that code DOES do something?" What the hell, that code never did, never does and never will do anything so just friggin delete it already! And here's a real gem, "I'm not sure if this code, that is in source control, is used so I'm going to comment out this block instead of deleting it completely (and I mean committing it like that)." What the hell do you even know how code works!? I agree that some code SHOULD not be touched because the chances of it breaking are far to big. However, ultimately not being able to find out what some code does or even not daring to change it after you've found out is just an indication of not knowing what the hell you're doing.Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
I've met a developer who was afraid to throw away some code that was never reached, something like
if (false) { ... }(maybe some test code once?) because "what if that code DOES do something?" What the hell, that code never did, never does and never will do anything so just friggin delete it already!I have seen it do something before... I worked on a project written in C for an embedded platform. The memory management was so horrible, it would declare global arrays of int16 in one file, and process them as extern int32 in other files. Many of these arrays held results of tests and pointers to other methods that had to execute. You may thing that if (false) { do something } is never reached. But on that system, you actually could not guarantee the code processed line by line! There were some wild hacks around it. Ultimately, I found the memory management problems, and everything began working in a predictable manner. I won't defend the programmer in your example, but I know why he/she was gun shy ;P Ultimately, there was a bigger bug to squash.
-
Programmers fear code because they don't understand it. That's why so few people can, and will do, a successful refactor. It's sad that so many people in our industry don't know their trade while so much can depend on it :sigh: As for that second part, who needs CPU anyway? :laugh:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
No, that's because they didn't right tests first.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Sander Rossel wrote:
I've met a developer who was afraid to throw away some code that was never reached, something like
if (false) { ... }(maybe some test code once?) because "what if that code DOES do something?" What the hell, that code never did, never does and never will do anything so just friggin delete it already!I have seen it do something before... I worked on a project written in C for an embedded platform. The memory management was so horrible, it would declare global arrays of int16 in one file, and process them as extern int32 in other files. Many of these arrays held results of tests and pointers to other methods that had to execute. You may thing that if (false) { do something } is never reached. But on that system, you actually could not guarantee the code processed line by line! There were some wild hacks around it. Ultimately, I found the memory management problems, and everything began working in a predictable manner. I won't defend the programmer in your example, but I know why he/she was gun shy ;P Ultimately, there was a bigger bug to squash.
Yeah, I know. When you mess around in memory directly anything can happen, but this was all VB.NET and C# development. No unmanaged code to be seen for miles :D
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
And you just cannot tell if a "bug" needs fixing, or if it was a deliberate attempt to handle bad input, or if it is now expected behavior downstream :((
That's true. Not really a bug, but I once worked on a form that took about 5 seconds to load. There was some multi-threading going on, but it wasn't implemented correctly. After I fixed it the data was shown almost instantly, but the menu items were disabled until the loading was actually done after about 5 seconds. I got a call, they rather watched at an empty and useless screen for five seconds than at data with a disabled menu bar :laugh:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
