why use #define?
For example: for some constant called "DECK_SIZE":
1.) You can change it everywhere at once (i.e., what if you want a 20 card deck, or a 54 card w/ 2 jokers?
2.) It makes it easier to see what is going on:
vs
Although, for stuff like this, you should use
1.) You can change it everywhere at once (i.e., what if you want a 20 card deck, or a 54 card w/ 2 jokers?
2.) It makes it easier to see what is going on:
for(unsigned int i = 0; i < DECK_SIZE; ++i) //very obvious vs
for(unsigned int i = 0; i < 52; ++i) //what is 52? is it special? or is it related to something else? Although, for stuff like this, you should use
const variables IMHO.
I kinda figured the 2nd one but it's never been an issue remembering that kind of stuff. The first one sounds neat though. Thankies :)
Don't get carried away though. If you need a zero, just use a zero.
There are some companies where people have to #define ONE, TWO, THREE, etc. Nonsense. Especially when, at some point, the following happens:
That may look funny, but it is really cold, hard, cruel truth.
There are some companies where people have to #define ONE, TWO, THREE, etc. Nonsense. Especially when, at some point, the following happens:
#define THREE 4 That may look funny, but it is really cold, hard, cruel truth.
Sometimes #define is a macro, so instead of having to type in a routine, you can just #define it. this can speed up runtime, because define is before runtime and calling routines happens at runtime.
@monkeyfeet:
It will be an issue at some point. For small programs, yeah, it's easy to remember. But for large programs (the project I work on is well over a million lines) it is easy to forget. Time also erodes memory.
@Duoas: OMG, did we work for the same company at one time???? We did exactly that. Everything you said. Including the #define THREE 4...
EDIT: That was in a previous job, not the current one...
It will be an issue at some point. For small programs, yeah, it's easy to remember. But for large programs (the project I work on is well over a million lines) it is easy to forget. Time also erodes memory.
@Duoas: OMG, did we work for the same company at one time???? We did exactly that. Everything you said. Including the #define THREE 4...
EDIT: That was in a previous job, not the current one...
Last edited on
What is this million+ line project? It sounds interesting; anything with more than 1000 lines of code is interesting; and many things with less...
Sorry, I prefer not to discuss it.
"Interesting" is an ... well, interesting ... way to put it. Projects of that size are so large that no single person can understand how it all works. Programmers at that point become specialists -- they become the sole author and
maintainer of a small subset of the overall project. They know the internal details of how their code works, and
they know the external APIs they use. Because they have the most knowledge, they can "maintain" the code
more easily than anyone else. They fix all the bugs in that piece of code, and they implement all the new
features. And it becomes a positive feedback loop.
It is a problem when they move on to other projects or other jobs because nobody will ever have as thorough,
detailed knowledge and understanding of the software the programmer wrote as the programmer himself/herself,
regardless of how much documentation they write. Even the original author will forget a lot of details if they aren't
dealing with the software routinely. I know. I've written a lot of code in the system that I work on, in many
disparate areas. I jump from area to area, depending upon what new features need to be implemented.
Some of the software I wrote six years ago was so simple at the time. All you had to do was derive
your new class from some base class, and override a few virtual methods. Today, I've forgotten all the
important details of how to do that -- what should function Init() do, when is it called, etc. It was simple
back then, yes, but time erodes even the best of memories. Looking back, yes, I did write copious amounts
of documentation -- design documents, code comments, etc. But still, neither the documentation nor the
comments add up to the knowledge I had when I wrote the software.
And that is why I always harp about maintainability and even why I often post messages like "here's a one-
liner that does the same thing". Less code to maintain, readability equal, is always better. Not only is it
easier to modify later, but it is quicker to understand.
IMO is slightly quicker to understand (provided the lambda expressions are readable to you; for anyone
beginning to learn boost::lambda, the above will be unreadable) than looking at an inlined custom
quicksort to do the same thing. Even though many programmers are able to look at the overall structure
of the code and realize it is sorting, there is still some text-scanning involved to figure out the sorting
criterion/criteria.
And IMO the above use of boost::lambda to define the sort criterion is slightly more maintainable than
writing the function object:
because, while both are equally readable to me, the function object is more typing, and if I ever want
to change the sort criterion, I either have to write another function object (more code to maintain) or
change its name in two places -- call site and declaration site.
"Interesting" is an ... well, interesting ... way to put it. Projects of that size are so large that no single person can understand how it all works. Programmers at that point become specialists -- they become the sole author and
maintainer of a small subset of the overall project. They know the internal details of how their code works, and
they know the external APIs they use. Because they have the most knowledge, they can "maintain" the code
more easily than anyone else. They fix all the bugs in that piece of code, and they implement all the new
features. And it becomes a positive feedback loop.
It is a problem when they move on to other projects or other jobs because nobody will ever have as thorough,
detailed knowledge and understanding of the software the programmer wrote as the programmer himself/herself,
regardless of how much documentation they write. Even the original author will forget a lot of details if they aren't
dealing with the software routinely. I know. I've written a lot of code in the system that I work on, in many
disparate areas. I jump from area to area, depending upon what new features need to be implemented.
Some of the software I wrote six years ago was so simple at the time. All you had to do was derive
your new class from some base class, and override a few virtual methods. Today, I've forgotten all the
important details of how to do that -- what should function Init() do, when is it called, etc. It was simple
back then, yes, but time erodes even the best of memories. Looking back, yes, I did write copious amounts
of documentation -- design documents, code comments, etc. But still, neither the documentation nor the
comments add up to the knowledge I had when I wrote the software.
And that is why I always harp about maintainability and even why I often post messages like "here's a one-
liner that does the same thing". Less code to maintain, readability equal, is always better. Not only is it
easier to modify later, but it is quicker to understand.
|
|
IMO is slightly quicker to understand (provided the lambda expressions are readable to you; for anyone
beginning to learn boost::lambda, the above will be unreadable) than looking at an inlined custom
quicksort to do the same thing. Even though many programmers are able to look at the overall structure
of the code and realize it is sorting, there is still some text-scanning involved to figure out the sorting
criterion/criteria.
And IMO the above use of boost::lambda to define the sort criterion is slightly more maintainable than
writing the function object:
|
|
because, while both are equally readable to me, the function object is more typing, and if I ever want
to change the sort criterion, I either have to write another function object (more code to maintain) or
change its name in two places -- call site and declaration site.
I have never seen anyone go over 400 lines of code :(
I agree:
I agree:
| It sounds interesting; anything with more than 1000 lines of code is interesting |
I have never seen anyone go over 400 lines of code :(
I agree:
I agree:
| It sounds interesting; anything with more than 1000 lines of code is interesting |
closed account (S6k9GNh0)
>.> I've gone over 400 lines using Unreal Script. No one even appreciated it accept for my own UT04 server. :/
That and I've gone over 400 lines coding a game I've yet to finish because it looks terrible and I'm not sure if I'm using the most effecient methods....
That and I've gone over 400 lines coding a game I've yet to finish because it looks terrible and I'm not sure if I'm using the most effecient methods....
I know but I haven't seen one my longest is probably the pig latin program ... which no one is commenting on T-T
| I know but I haven't seen one my longest is probably the pig latin program |
It was a fun idea...
I like the GNU fdisk program so I downloaded the source and I'm trying to figure out how it works. I have everything except actually getting disk information :)
Eventually you won't be able to tell it apart from:
|
|
Last edited on
I'm on 483 lines already for a school project...admittedly it's spread over 7 files and is really three projects put together, but...
Topic archived. No new replies allowed.