|
I guess we could argue this back and forth. It comes down to avoiding mistakes and doing things as a matter of policy.
E.g.
I never do this:
int* y, z;
I always do this:
int* y;
int z;
Why you ask. Too easy to read it wrong at a glance, too easy to miss something. Some logic as to why I never use goto's and why I don't put returns anywhere but at the very bottom or very top of a function.
I believe this to be more than just a matter of style.
|
|
|
|
|
That is an excellent paper! I rarely use goto , but sometimes it is the best solution to a problem. (Example: escaping from multiple nested loops.)
I once read someone’s general rule that you always go forward, but I found one exception years ago:
NEXT_BYTE:
if( x>xmin ) {
Byte = *(--vptr);
if( Byte == 0xFF ) {
x -= 8;
goto NEXT_BYTE;
}
}
Sure the above code could be written using a loop and originally was, but this increased the speed (graphics code) enough to justify its use at the time.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I once came across an Access database (already WTF) that used columns instead of rows for a Calendar like application ! The Calendar table had (from memory) 1 row for each day with 50+ columns for each half hour block from 8:00am. Now you can imagine the horror it was to try to maintain such an application. The reports that ran of this dog were nightmarish, even to SELECT a single day that had 'something' happening on it looked something like
SELECT * FROM Calendar WHERE Time800 <> '' OR Time830 <> '' OR Time900 <> '' .. OR Time1600 <> ''
I can imagine what the coder would have said when asked to make the days start a little earlier than 8:00, "Oh, sure, that'll take at least another 4 months to re-schema the database and touch up all the affected queries".
And when the original developers were sacked for taking way took long and we took over the project we were questioned why we were completely rewriting it from scratch. The above Calendar table was just one example in this diseased rats nest, there were plenty of others like using hidden form controls as global variables. You would open up the main form and had absolutely no hope of actually telling what it would look like when run since it was completely covered in these demons from hell. I just hate with a passion code that does not read simple, I hate it when I cannot confidently make a simple change to some code without it screwing up something completely unrelated because the variable I modded was global and had different meanings depending on where it was called from.
Anyway that's my rant
Code should be simple. No excuses.
|
|
|
|
|
Steve Fillingham wrote: 1 row for each day with 50+ columns for each half hour block from 8:00am
More than 50 half hours after 8am? Which planet was that calendar designed for - mercury or venus?!?
|
|
|
|
|
I wager the developers put in extra hours for leap years.
Brad
Australian
- Captain See Sharp on "Religion"
any half intelligent person can come to the conclusion that pink unicorns do not exist.
|
|
|
|
|
Good pickup I dont know about the Calender but the dev was definitely not of this Earth
|
|
|
|
|
This jewel is one of my favourites. I found it in a customer's code (they asked us to enhance the application):
BOOL cIBatchDownload::OnInitDialog()
{
if (m_bCreated)
{
}
...
return TRUE;
}
I eager to look deeper into this code to find more post for this newly created forum.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine.
Personal Site
|
|
|
|
|
Hmmm!
I have done that when outlining the code before filling the in-betweens. The real question is: what was supposed to be inserted there?
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Once upon a time, I was leading a team that was doing the server side of an internet banking application. Because this sort of app was in its infancy, there was little confidence, and a lot of paranoia. IIRC, the flow was that a connection would come into an external server, a session would be created and packed and sent across a serial cable to the machine that would handle authentication. This packet would be decrypted, verified and sent back, then it would move on to another machine across another serial cable for the transaction. We had essentially the same process running on each machine, but operating a bit differently depending on the role.
ANYWAY ... we had a problem in that sometimes, a session would drop out, and the service would crash. We logged, we debugged, we stepped through, and couldn't find it, until one fine day, we hit a breakpoint, and the developer said "Huh. That's funny. That should be a session object, not a data chunk."
The penny dropped. "Ah," I said. "That session ID that you're passing back and forth between machines ... is that an index into the session array, or what?"
"No," came the bemused reply. "I thought it would be quicker to just use the address of the object".
Apparently, the original object had been deleted because the session had been dropped, and the runtime had reused the space for something else. So when the session ID was cast from its session ID form (int) to its pointer form, it was pointing at something else. Don't get me wrong ... I love pointers. I just had no idea that their abuse would be extended to neighbouring machines.
-- modified at 23:41 Monday 5th March, 2007
--
All things considered, you can't really consider all things ...
|
|
|
|
|
I was once maintaining some odd looking code that had the (no joke) the following pattern:
<br />
int variable;<br />
<br />
class CSomething {<br />
public:<br />
int variable;<br />
<br />
void Func(int variable) {<br />
{<br />
int variable;<br />
}<br />
};<br />
};<br />
Count them: FOUR declarations of the same variable name (and type) in the same file!
1) In the global scope
2) As a member var
3) as a function parameter
4) declared IN SIDE the function that has the identical named param
Yes, it was legal - but it didn't make it right.
[ Jason De Arte | Toy Maker | 1001010.com ]
|
|
|
|
|
Makes me remind of the last programming exams i took... They make you go insane with a snippet 10 times difficult than the above, then they ask you "WTF does var on line x refer to, which is its value?"
Someone just never learns
|
|
|
|
|
Whilre reviewing the code from some contract developers, I have found a common construct:
<br />
public void SomeMethod()<br />
{<br />
try<br />
{<br />
}<br />
catch (Exception exception)<br />
{<br />
throw exception;
}<br />
}<br />
Why just catch and re-throw an exception? This just adds to the complexity of the execution without doing anything in return.
|
|
|
|
|
I would wrap that in an # if DEBUG ; too many times when debugging I can't figure out where an exception happened, especially when there's a finally involved.
|
|
|
|
|
Yep it can be useful for debugging. Anyway, I'd use just throw; to rethrow exception, as that way I don't lose stack trace IIRC.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
You know you can get VS to break on exceptions when debugging so even if the code is wrapped in a try - catch / finally block it'll always break when the exception is thrown rather than when it's un-handled.
|
|
|
|
|
I agree with the use of conditional statements for this purpose, but they are not there and this is supposedly debugged code. I can also see re-throwing if there is a finally block cleaning up, regardless of the use of conditionals.
What I didn't show was that there are typically three or four lines of code inside the try block...
|
|
|
|
|
I once worked with a programmer who wrote code like that. He yelled at me (in front of the big boss) for getting rid of it. It turns out he wasn't aware that .Net puts a stack trace in Exception objects! The real lesson that *I* learned is "old habits die hard"; he was still using techniques from back in the C++ / COM days.
|
|
|
|
|
I feel you pain. Old habits do die hard, so the trick is learning the right habbits. Asking yourself "Do we have a backup?" is the best habbit to have. Beyond that is a functional understanding of what the compiler is doing to your source, regardless of the language. Unfortunately too many people try to compare a medium-level language like C or C++ to a high level language like C# based on the syntactical similarities alone.
|
|
|
|
|
Actually, this code has a somewhat subtle behavior, since it is catching by-value, prior to throwing.
If a derived exception is thrown, it will be "clipped" to the base class when it is thrown. This could be potentially
different from invoking throw, which would throw the derived class.
|
|
|
|
|
One of my favorite incidents happened over 10 years ago when computers were much less powerful. An engineer came to me with a financial forecast spread sheet that was taking 4-6 hours to run. After speaking with him about what he was attempting to accomplish, I rewrote his application in FORTRAN (the engineering language of choice at that time) and he was able to do an analysis in 6 seconds! That is not a misprint.
This engineer was intimately familiar with spread sheets, his only tool was a hammer, so everything looked like a nail.
Brian Leach
|
|
|
|
|
Brian Leach wrote: This engineer was intimately familiar with spread sheets,
won't touch it. nope. not gonna.
|
|
|
|
|
I'm going through the same thing now, inherited a bunch of Excel "reports" to maintain. Oh, the horror!
-- modified at 20:29 Monday 5th March, 2007
Oh, and... every tool is a hammer.
|
|
|
|
|
VBA/Excel03 still has the same performance penalties over modern languages. >30min to ~1s (timed from button click to completed dialog appeared, so a decent chunk of that second was form loading)
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
In the last company I worked (about 8 years back), I was asked to fix a bug in some invoice processing module. The main code was in a single function which had about 30,000 (hyperbole, don't remember the xact no but it was enormous) lines which is a WTF in itself. It was a common practice in the whole application. When looking at the issue to solve, I also found that there was a major issue that caused the code database to rollback even when the processing was successful. Believe it or not the issue was that braces did not match properly in that 30000 lines of code. I wish I kept the original code but after struggling for about a day I finally re factored the code and separated into various functions and made it work.
It did not here. Some people working at a client's place found the issue of Rollback and notified the team leader. The team leader compared the code and thought that it was my changes that lead to this issue. I debated with him for lot of time but apparently he did not like the idea of clean code. He (who also happened to like me) had worked with the app for about 5 years and was probably not used to the clean code. Finally, the QA tests revealed that my code was the one which was working properly. However, I still had to remove all the refactorings I did to my code (mostly function extractions) and put back in that one large function.
Needless to say that I left the company in another 2 months.
|
|
|
|
|
Yup. That is one issue that sneaks up on all of us. In the past I've had to "make only those modifications that will fix the described issue" for what were called patch builds. And as you can guess, when the customer received and used the "fixed" code, it broke just as badly as before. That company is now struggling to survive.
Phil
|
|
|
|