|
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
How the hell do people even come up with such sh*t?
|
|
|
|
|
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.
|
|
|
|
|
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 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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Marc Clifton wrote: while (completedTheadIds.Count == 0) { }
Um.... um... um........
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
|
|
|
|
|
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.
Marc
|
|
|
|
|
Well, if they were expert JavaScript coders, their string booleans should've been in single quotes.
Jeremy Falcon
|
|
|
|
|
Found a similar comment:
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...
|
|
|
|
|
In an e-mail I received this morning: "Since the view is being pulled every day, their ... numbers fluctuate ..."
Maybe that's why the stupid thing is so bobbing slow!
I've been wondering why they insisted that I read the view only once a week.
|
|
|
|
|
Whiskey.
Tango.
Foxtrot.
Whoever wrote that view needs to be drawn and quartered. Then each piece quartered again. Then those chunks dumped into a lava pit.
It's called a VIEW for a reason, people!
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
N_tro_P wrote: A view can't actually change the data as it is or its not a "view" per say ..if the underlying data changes, and they request the results of the same view two weeks later? You expect the same results, or new ones?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
That depends on what's backing it.
In many cases, the tables are "live" and you expect the latest data every time you read the view.
In other cases, the tables are in a "reporting" database that might contain "the state of the data as of close-of-business yesterday" and you would not expect different data throughout the day.
In that case, something would update the reporting database in the evening.
But, it seems like somehow they got this view to perform that update! So they want others (me) to call it once in the evening, but not during the day.
I'd rather get the updated data, but others are reported as being "confused" by having the data change.
|
|
|
|
|
|
N_tro_P wrote: It sounds more like a view was causing the data to actually change meaning a query was doing adding to the data set which is against all view policies. A view does not have side-effects.
Adding a row is not the same as a view with side-effects
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Or even better: Some triggers.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Wait, that's actually allowed? In all my years I've never attempted to update the DB in a view. I mean who would?
Jeremy Falcon
|
|
|
|
|
Yep, I found this out a couple of weeks ago when faced with a challenging client who insists on keeping two systems (databases)...one receives data automatically as a daily scheduled task from their receiving and pos systems while the other holds the same data but in monthly summary, and after passing through the accounting dept/system. Looking for an easy way to keep 95% of the shared tables in synch, I decided to try recreating the shared tables as views in one of the databases. I was fully expecting an error when creating a new record in a view...but it did what it wasn't supposed to do. It still confuses me, but at least it solves the problem at hand.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Oh... Emmm... Gee
Jeremy Falcon
|
|
|
|
|
Access?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|