|
Don't forget expressiveness.
|
|
|
|
|
Look on the bright side... at least if the specs change in the future and you actually DO need to do something when those conditions are true, the structure is already in place...
|
|
|
|
|
Scott Barbour wrote: Look on the bright side... at least if the specs change in the future and you actually DO need to do something when those conditions are true, the structure is already in place...
Sounds like somebody might have been thinking ahead...
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
I have never really posted on code project, but this just made me angry that someone would put this into a production code base! I tried to drop the entire sample into here, but I think there is a limit so I snipped out repetitive parts (which is pretty much all of it). Anyways, the guy also indented the thing so it was like 200 characters wide at the last nested if!
If intColumnnum = 1 Then
crDField(pcounter).Width = 2475
crDField(pcounter).Left = 240
intColumnwidth3 = 2475 + 240
intColumnwidth3 = intColumnwidth3 + 60
Else
If intColumnnum = 2 Then
crDField(pcounter).Width = 990
crDField(pcounter).Left = intColumnwidth3
intColumnwidth3 = intColumnwidth3 + 990 + 60
Else
*SNIP*
If intColumnnum = 38 Then
crDField(pcounter).Width = 2400
crDField(pcounter).Left = intColumnwidth3
intColumnwidth3 = intColumnwidth3 + 2400 + 60
End If
*37 more End Ifs*
|
|
|
|
|
Why does the choice of language here not surprise me..
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
|
|
|
|
|
I think I have said before, its not the language that's at fault, its the ability of the developer in question that wrote these lines of code! You could do exactly the same thing in any programming language..
However unfortunately the fact is that most developers of a questionable ability develop in that language!
|
|
|
|
|
I agree it is not the language.
I think that Visual Basic was a marketing trap: the appealing smoothness of its learning step made it be considered the language for all, hence many, many people became at once programmers, very poor programmers, in fact.
I know (few) skilled guys using VB6 and also a bunch of pretty weird C++ coders.
Another reason maybe that, usually, skilled people like to challenge themselves with more complex (and powerful) languages, leaving VB to less skilled ones.
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]
|
|
|
|
|
I know C# and VB, I have tended to code in the past using VB, but I do use the language properly and make use of all the features available. I do agree VB Was marketted as the language for all, unfortunately it has caused a minority (slowly becoming a majority) to market themselves as professional programmers when they are nothing more than hobbyists, and this reflects in the quality of code produced.
I always ensure Option Strict is turned on when programming  but again if VB was a proper language it should never allow you to turn it off! I have seen too many coding horrors where it has been turned off due to programmer laziness.
VB used to offer many advantages (disadvantage?) in being able to create applications quickly but this is being eroded by the likes of C# and other contempary languages. I am planning to move more of my development over to C# over the coming months and migrate legacy systems as and when required, mainly as I want my internal team to code properly!
|
|
|
|
|
 ( pretty much sums it up for me )
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
It depends what the life of the code is indended. If it was a short term piece of interim code then perhaps it might be justifiable (perhaps even on performance grounds)
|
|
|
|
|
I found this expression in our current source code:
int i;
(int)pow(2,i) This was in code written by a senior developer .
I replaced it with the following expression:
(1 << i)
Software Zen: delete this;
|
|
|
|
|
I'd have to see more of the code to decide if this really deserves to be a horror. It's possible that, as an optimization, "fixing" this has zero impact on real world performance while (slightly) obfuscating the code.
I'm a much bigger fan of readable code than optimizations with negligible performance improvements. (Not that "2 << i" is that unreadable, but you get the idea.)
Faith is a fine invention
For gentlemen who see;
But microscopes are prudent
In an emergency!
-Emily Dickinson
|
|
|
|
|
Shift left is way cooler than pow any day. And in the end it's all about how good the code looks, eh?
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
words to live code by! 
|
|
|
|
|
Words of wisdom, I can often spend hours getting my comments and keywords in the right places to make the code look good and colourful
Paul
|
|
|
|
|
I'm uncomfortable saying this 
No, it is all about the app meeting the requirements.
One of the requirements (too often, only implied) is that the code be readable and maintainable. It may be that << is better looking than pow in some cases, but maybe not. What if that was coding a requirement directly? I would expect any coder worth his salt to understand and translate, but I know too many programmers that are not worth their salt.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
David Kentley wrote: It's possible that, as an optimization, "fixing" this has zero impact on real world performance while (slightly) obfuscating the code.
I'm pretty sure pow() only takes and returns doubles which means the original code is casting two ints in and one back out in addition to its internal pow goodness. I'm guessing the shift is a wee bit faster.
|
|
|
|
|
Robert Surtees wrote: I'm guessing the shift is a wee bit faster.
Which, as was argued here, is very probably of no importance, while the resulting obfuscation of the intent of the calculation is important.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
jhwurmbach wrote: Robert Surtees wrote:
I'm guessing the shift is a wee bit faster.
Which, as was argued here, is very probably of no importance, while the resulting obfuscation of the intent of the calculation is important.
I'd say it's important. Gary's XT doesn't have an 8087 plugged in.
|
|
|
|
|
Based on what he was using this for (constructing a bit string), I would say using the pow() obscured the intent more than the shift operation did.
Software Zen: delete this;
|
|
|
|
|
Robert Surtees wrote: I'm pretty sure pow() only takes and returns doubles which means the original code is casting two ints in and one back out in addition to its internal pow goodness. I'm guessing the shift is a wee bit faster.
VC++ compiler is smart enough to implement it using shift instead of pow.
Anyway, IMHO shift syntax is far more clean.
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]
|
|
|
|
|
The original surrounding code looked something like this:
for (int i = 0; i < 16; i++) {
CString name;
name.Format(_T("Stuff_%d.dat"),(int)pow(2,i));
};Thinking about it, if I wanted to maximize readability, I would have done this:
int name_value = 1;
for (int i = 0; i < 16; i++) {
CString name;
name.Format(_T("Stuff_%d.dat"),name_value);
name_value *= 2;
};The only reason I found this is a compiler error in the original (int)pow(2,i) expression from VS2008 (ambiguous override).
Software Zen: delete this;
|
|
|
|
|
David Kentley wrote: Not that "2 << i" is that unreadable, but you get the idea.
In fact it isn't unreadable, it is wrong.
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]
|
|
|
|
|
Can you guarantee that floating point inaccuracies + truncation in the cast doesn't introduce a problem?
A quick check shows they don't on VC8, but I wouldn#t have bet on it.
Further, if your compiler uses the canonical (if simplistic) implementation of
double pow_simple(double x, double y) { return exp(y*log(x)); }
you fail pretty quickly with pow(2,3) = 7.9999999999999982
To add a pitfall to a lurking bug: if you use the default %f specifier for that, it dutifully prints 8.000000, but truncates it to 7 when casting to int.
Also, when using 64-bit integers, starting with pow(2,51) double loses on accuracy.
|
|
|
|
|
That is the first thing I thought of when I saw this. The thought of converting floating point to integers using casts keeps me awake at night.
I am actually currently working on a project at work that has a few of these. I just started here at the time I noticed them. For fun, I thought it would be neat to try compiling this project (which was developed in VC++ 6.0) with VC 2005, and VC 2005 choked on these instances. Good job to the compiler team on that one. It also choked on a few things that I thought VC++ 6.0 should have, such as assigning an int literal to a CString. A few more bonus points to the team there, although 6.0 definitely should have caught that.
Of the pow(int,int)s, at least one could've used the x *= 2 form, as it was in a loop, and the others the shift form. In the end, I decided not to touch any of them, because for all I know the truncation does mess things up but somebody spent a bunch of hours putting in "fixes" to work around this. The routines in question don't seem to have any bugs for now, but since a lot of the other ones do, I decided to focus my energy on those.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
