|
Why literal 14 is bad, bacause its not clear WHY it's 14. Isn't it mistake? Shouldnt it be 15? or 13? What the hell that number means. If you say that it's actually number of days in two weeks, it's better. No matter HOW you say it.
It's you who is talking about how plain english syntax is great and c-like syntax sucks, over and over like a mad man.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
dnh wrote: If you say that it's actually number of days in two weeks, it's better. No matter HOW you say it.
But HOW you say things does matter; some ways are better than others. Surely you can see that "repeat this 14 times" is easier for the average English-speaking person to grasp than "for(int i=0;i<14;i++){...}".
It's obvious that programmers here use certain principles, like clarity and naturalness of expression, to distinguish bad "C" code from good "C" code; but they frequently refuse to apply those very same principles in a larger and more general sense. It's a curious phenomenon.
|
|
|
|
|
The Grand Negus wrote: But HOW you say things does matter; some ways are better than others.
That was not subject of this debate, but you exactly nailed your problem.
The Grand Negus wrote: Surely you can see that "repeat this 14 times" is easier for the average English-speaking person to grasp than "for(int i=0;i<14;i++){...}".
Why not throw away language of math when you are at it, and come back to, hmm, what? Early greek philosophy?? Mathematicians have natural language at their disposal since ever. Yet, they keep developing and using symbolic formal language(s)... How so? Maybe some ways are better then others. Sure, average Joe doesn't understand http://mathworld.wolfram.com/RampFunction.html[^]. So what, average Joe doesn't care about Fourier transform, either.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
It's curious that you should pick the ramp function as an example, for I would argue that this particular function is much more easily (and understandably) described algorithmetically and that the language of traditional mathematics is therefore not the ideal representation for things of this sort. In fact, when described in a algorithm - or better yet in a natural language - the "average Joe" can understand the ramp function; it becomes trivial. The mathematical notation in this case obfuscates the thing.
That's why we find that the language of mathematics is capable of describing only tiny little bits of reality, while natural language has been used to describe, meaningfully, nearly everything that we (as a species) have ever encountered. What's the formula for a rose, or an ocean? for love or hate or courage or cowardice?
|
|
|
|
|
The Grand Negus wrote: It's curious that you should pick the ramp function as an example
It was random pick 
The Grand Negus wrote: What's the formula for a rose, or an ocean? for love or hate or courage or cowardice?
What's your point, do you often use "love" or "courage" in your programs? 
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
The Grand Negus wrote: It's a curious phenomenon.
Yes it is. Despite everything you are still using this as a forum to pimp PE.
This statement was never false.
|
|
|
|
|
Strictly speaking, C doesn't either; the "C preproccessor" does, and I can use the "C preprocessor" with C#, or VB, or T-SQL, or any other text file.
But, yes, in C# I would use const or maybe even an enum.
|
|
|
|
|
PIEBALDconsult wrote: On a side note; the guru insisted we use defines rather than consts to conserve memory.
Many times the optimizer will not actually reserve memory for consts unless you do something like take the address of it. But, if you do use the consts, you get the added benefit of compiler-checked type safety.
--
Marcus Kwok
|
|
|
|
|
PIEBALDconsult wrote: On a side note; the guru insisted we use defines rather than consts to conserve memory
Holy s**t!
Are you working in a ultra restricted realtime environment with only 16 bytes of RAM or what?
Otherwise, of course you already know it, but someone ought to explain the new and shine idea (only 20 years old!) of type safety to the guru.
--
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
Math might change in the future and you want to have dynamic code! 
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that." - Tommy Boy
"Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School)
|
|
|
|
|
Just laziness. Although I remember in one language I wanted to write a massive for loop. However I couldn't type in the integer literal because of the compiler. (the number was too big?) So I used mulitplication. (At the time it didn't occur to me to use hex)
File Not Found
|
|
|
|
|
Strange one, I'd say its probably due to someone modifying legacy code - that's not to say they knew what they were doing
|
|
|
|
|
for(int i=0;i<=7*2;i++)
I often do this kind of thing when I have well-known constants in my code (e.g., 7 days in a week, 2 possible bit values) that aren't worth something like:
#define DAYS_ON_WEEK 7
#define BIT_VALUES 2
But I only do this kind of thing for constants that are immutable and extremely obvious to the context (hey, sue me when bits can store something different from 0 and 1).
This way, writing 7*2 can be more readable than 14 and the compiler will output 14, anyways.
|
|
|
|
|
It helps to show that a certain "constant value" is made up by other values.
In this case he probably has stored 2 * 7 values in one array or something.
V.
I found a living worth working for, but haven't found work worth living for.
|
|
|
|
|
If you are doing to do something like that you should at least put it in parenthesis with a comment attached to it.
for(int i = 0; i <= (7 * 2 ); i++)
{
}
It looks a little crappy but if you could see the code colorization it would look much clearer.
However it would be wiser to do this.
for(int i = 0; i <= (14 ); i++)
{
}
Describe what 14 is.
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
It is also useful for programmers that can count only up to 10.
|
|
|
|
|
|
A couple of year ago, I worked for a compagny who were making vision sensing application for wood machinery. Their code (in C++) was a lot complicated, with lots of subclassing, and for the worst part of it, almost every options parameters controlling the code sequence were implemented with #if #then to "save some processor time". (The main core of the program was developped in Turbo-Dos like 15 years ago, then ported to Visual 6.0. It's why they used those #if #then...) The code was more than 3 millions line of code!!!
That's it for the introduction. (You may already laugh!!)
But one day, I came across a fonction used to connect a RS232 port.
This is the interesting part inside the fonction :
...some code here
if( strcmp( lpszPortName, "COM1") == 0 );
{
// Connect the COM1 port
...some code here
}
else if( strcmp( lpszPortName, "COM2") == 0 )
{
// Connect the COM2 port
...some code here
}
else
...
So I asked one of the guy who were working there since a very long time, why they didn't corrected that error... He told me "It always worked well before, and the compiler never notified any error so leave it like that..."
Do you know why I found this little error in 3 millions of code lines? Because this sequence was part of a library used in the main program, and because that library had never been recompiled since its first release 10 years before! For some reasons, I just forgot to follow a little "office rule" that was to never recompile all projects in a workspace in a single shot. I did it "oh unfortunately" then the compiler hit that error immediately!!
Progamming looks like taking drugs...
I think I did an overdose.
-- modified at 3:09 Tuesday 13th March, 2007
|
|
|
|
|
I had to stare at that for a good 30 seconds before I spotted the bug. Gosh - I need a decent compiler at this time in the morning to help me!
|
|
|
|
|
|
Ok, it took me a while to see the ";" after the first "if". You would have done me a great favor by simply mentioning that in your message. It's funny!
I just wanted to say that I know what you mean. I'm stuck with something similar. Lots of code doing nothing. I can't believe you actually took the time to count the lines of code! All I can say is that the program I have to work on has about 30000 files of source organized in about 2000 folders.
So, if there were about 400 lines of code per file, that would make a total of 12 million lines of code! However, that's an understatement, since most files have more than 400 lines of code.
When I run into errors like this I think a lot about whether I should fix them or not, since doing so might actually be causing a bug. ) I took up assembly language a long time ago, just because of this. C++ and all other high level programming languages are supposed to be related a great deal to human language. But people say stupid things all the time.
|
|
|
|
|
|
Real nasty ones these; you just read straight over the problem and not notice it 9 times out of 10.
Steve
|
|
|
|
|
This is a good candidate for the Subtle bugs forum.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Not if they determined "it's not a bug".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
