|
|
<br />
int pow(int i, int j)<br />
{<br />
switch (j) {<br />
default: return 0;<br />
case 0: return 1;<br />
case 32: i *= i;<br />
case 31: i *= i;<br />
case 30: i *= i;<br />
...<br />
case 1: return i;<br />
}<br />
}<br />
....
ewwwww
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
|
(stack madness variant)
int imul(int i, int j)
{
if (j==0 ) return 0;
else return imul(i,j-1) + i;
}
int ipow(int i, int j)
{
if (j==0) return 1;
else return imul(ipow(i,j-1) , i);
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Gary Wheeler wrote: This was in code written by a senior developer
When seniority approaches retirement...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Do you work for the same company as me? I've seen someone write code just like that -- to create a bitmask.
|
|
|
|
|
But... but... but... this ISN'T VB...
Is it possible to have bad code written by a senior developer in a non-VB language???
|
|
|
|
|
We senior developers are very resourceful!
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
Gary Wheeler wrote: (1 << i)
Moral of the story. Shift happens.
|
|
|
|
|
<DeepMysteriousVoice>
You have become known to us. Your capacity for puns is disturbing...
</DeepMysteriousVoice>
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: <deepmysteriousvoice>
You have become known to us. Your capacity for puns is disturbing...
A curse upun you.
|
|
|
|
|
Quoting Peter Lorre in The Raven[^]:
"Ah! You defend yourself, you coward!"
Software Zen: delete this;
|
|
|
|
|
It's a documentation rather than a coding horror, but to good to let it pass.
Either I'm seriously missing something, or MSDN has gone really bonkers.
msdn:DllMain[^] writes:
There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL.
So far so good, so true.
But now, what does MSDN recommend to make that initialization automatic?
Alternatively, the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist.
If complex per-process initialization is required, use a "private" global flag. If cross-process initialization is required (that's what would be closest to creating a file...), use a flag in a shared data segment.
modified on Tuesday, December 25, 2007 4:00:09 PM
|
|
|
|
|
I am not sure about that.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
I agree whole-heartedly with their solution.
peterchen wrote: If complex per-process initialization is required, use a "private" global flag
...You mention "complex" and then "private global flag" in the same sentence??
To me..."complex" would imply...well.....complex.
And "private global flag" would imply....well....an improper implementation for a "complex" solution
A "private global flag" (regardless of the fact that declaration of anything with global scope is incorrect) would create an incredibly fragile, convoluted solution. Creating an access list (along with the other MSDN suggestions) would be extensible and compartmentalized.
"I need build Skynet. Plz send code"
modified on Thursday, January 03, 2008 10:04:15 AM
|
|
|
|
|
the gist of it:
flag=bad;
"I need build Skynet. Plz send code"
|
|
|
|
|
"complex", in the context of above post, meaning "anything you may not do in DLL Main" (such as loading other DLLs).
How would creating an "access list" make the decision when to run some initialization "extensible and compartmentalized"? Please provide a sample.
Alaric_ wrote: And "private global flag" would imply....well....an improper implementation for a "complex" solution
The initialization may be complex, but the decision where to call it may be very simple.
Alaric_ wrote: declaration of anything with global scope is incorrect
If you said "questionable", I could follow you - while still arguing that it depends on the scenarion. But with such a blatant statement... do you know what "global" means? In what way would a file be "more" or "less" global than a variable in a private data segment? Can you argue for your point?
the gist of it: global flag not always bad.
|
|
|
|
|
I found this piece of VeryBAd VBA code in an Excel spreadsheet I was amending today:
For counter = avgfirstrow To avglastrow
cellvalue = Sheets(1).Cells(counter, 3).Value
If cellvalue < 0 Then GoTo ignore
If cellvalue > 99 Then GoTo ignore
totalsum = totalsum + cellvalue
GoTo nextone
ignore:
entries = entries - 1
nextone:
Next
I can assure you my left eyebrow is still twitching.
Gibber gibber....
My only guess is that Satan must have been whispering into my colleague's ear at the time.
You always pass failure on the way to success.
|
|
|
|
|
Is your anger mainly directed to VBA or to your colleague's code? What if your colleague wrote the following instead?
For counter = avgfirstrow To avglastrow
cellvalue = Sheets(1).Cells(counter, 3).Value
If cellvalue < 0 Or cellvalue > 99 Then entries = entries - 1
Else totalsum = totalsum + cellvalue
Next
The reason I ask is many people seem to be happy with denouncing anything with VB in it, not realizing that it is possible to write good code in VB/VBA, just like it is possible to write bad code in C++/C#.
Thanks.
|
|
|
|
|
Xiangyang Liu wrote: Is your anger mainly directed to VBA or to your colleague's code?
My colleagues lack of coding proficiency(What a Scrooge I am and it's Chistmas tomorrow).
Unfortunately I have not been supervising his coding enough.
It's a tricky area as happy coders make better coders - so I try to have a light touch when it comes to others code.
Although I do like to have a good old moan on CodeProject occasionally.
Xiangyang Liu wrote: it is possible to write good code in VB/VBA, just like it is possible to write bad code in C++/C#.
I agree.
My experience is that VBA encourages bad techniques and habits.
To code in C# you have to have a relatively good understanding of programming methodology(am I wrong?).
You can throw anyone at VBA and it will throw something back up.
Xiangyang Liu wrote: What if your colleague wrote the following instead?
I would have had nothing to complain about except for the formatting(there I go again).
Merry Christmas
Guy
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: To code in C# you have to have a relatively good understanding of programming methodology(am I wrong?).
True. VB family supports unstructured error handling like On Error Resume Next but such constructs are totally not supported in C#.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
I agree with you. Is the average VB programmer who brought discredit on the language.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
"Omit needless local variables." -- Strunk... if he'd taught programming
(cellvalue in this case)
|
|
|
|
|
Thanks - I missed that one as well.
Merry Christmas
You always pass failure on the way to success.
|
|
|
|
|
Actually his usage of a private variable was correct, because otherwords he would have to keep drilling down the object model to get the value in each conditional, and it's better to incur the performance overhead of allocating a new variable once than to keep traversing the object model more than once in a loop like that. "Real" VB (which is NOT the same as VBA) gives you the With statement which prevents the need for this additional variable. What he did actually makes the code more readable as well.
Keep in mind that VBA is meant for simple macros, so there is really no horror in what he did, even with macros. Gotos are considered bad because they lead to spaghetti code smells in applications that have grown beyond a particular size, but used in a small macro situation they can greatly enhance readability if used properly.
I'm not trying to wave the VB banner, I actually bailed on it quite some time ago only using it when I have to, simply because most good developers chose to focus on C#, thus it's easier to go with the flow and I like C-like syntaxes.
But most VB-bigots are not as smart as they think they are and would feel quite stupid for making blanket statements about VB if they knew all the facts. I've seen really amazing, robust, well-performing apps written in both VB6 and VB.Net, and VB itself incorporates many elements of Pascal which is an excellent language.
I do agree that the relative simplicity of getting started with VB led to an influx of bad programmers (many of which got flushed out in the dot com bust), or people who were uneducated in formal CS concepts or simply were not technical or motivated enough to make a career committment to good programming, but at the same time I've worked with some real idiots whose background was in Java or C++. I always thought Microsft screwed up by keeping the whole "BASIC" moniker... when they came out with .Net they should have just named it B++ or B# or something that made more sense, because despite a few syntax differences it is much closer to C# than it is to the original BASIC.
|
|
|
|