| monkeyfeet (6) | |
| Why not just put the number itself in? | |
|
|
|
| firedraco (5414) | |
|
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: 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.
| |
|
|
|
| monkeyfeet (6) | |
| 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 :) | |
|
|
|
| Duoas (6734) | |
|
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: #define THREE 4 That may look funny, but it is really cold, hard, cruel truth. | |
|
|
|
| mspy2plus (28) | |
| 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. | |
|
|
|
| jsmith (5804) | |
|
@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... | |
|
Last edited on
|
|
| chrisname (5896) | |
| What is this million+ line project? It sounds interesting; anything with more than 1000 lines of code is interesting; and many things with less... | |
|
|
|
| jsmith (5804) | |||||
|
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. | |||||
|
|
|||||
| DrChill (574) | ||
|
I have never seen anyone go over 400 lines of code :( I agree:
| ||
|
|
||
| DrChill (574) | ||
|
I have never seen anyone go over 400 lines of code :( I agree:
| ||
|
|
||
| computerquip (1892) | |
|
>.> 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.... | |
|
|
|
| DrChill (574) | |
| I know but I haven't seen one my longest is probably the pig latin program ... which no one is commenting on T-T | |
|
|
|
| chrisname (5896) | ||||
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
|
||||
| demosthenes2k8 (174) | |
| 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... | |
|
|
|
| chrisname (5896) | |
| What is it supposed to do? | |
|
|
|
| demosthenes2k8 (174) | |
| It's got code for Stacks, Queues, and linked lists... | |
|
|
|
| chrisname (5896) | |
| That reminds me I need to learn sorting alogrithms and linked lists and what not. | |
|
|
|