Pages: [1]
|
|
|
Author
|
Topic: Source Code Format (Read 1922 times)
|
harth1026
*Many bubbles*
Offline
Gender:
Posts: 142
|
This is basically more of a rant than a question... Anyway....
I've been playing around with the source code to see how it works and to see if it's possible to add the SC1 tactical/strategy mode in it somehow. While I still don't know completely how the code works, I'm not going to complain about how effective the algorithms are. However, there are a few things I will say about the format of the code that really bothers me.
- I really hate the fact that each line is 76 chars or less. I really don't know who benefits from this, but it makes the code really hard to read when I have to read 4 lines of code to see the control statement of a for() loop. - I really hate it when functions are used as arguments for other functions. This complaint coupled with the first one makes me wonder what the hell is going on in this code. I do this too, but not this often. This is probably a helpful optimization trick for older computers and the 3DO, but we're running quad-Xeon 200.4 GHz machines with hyperthreading and 256 GB RAM. We don't need this anymore. - I really hate the lack of '{' and '}' in the code. I know if there's only one line of code after a for() loop or an if() statement, you don't need them. But when you couple this with the other two complaints, you have ultra unreadable code. And there really is no benefit to leave them out.
If you can actually read the code in that format, more power to you, but it is just frying my brain. Anyway, now that that's out of my system, I will shut up now and get back to work..
|
|
|
Logged
|
|
|
|
|
harth1026
*Many bubbles*
Offline
Gender:
Posts: 142
|
No problem. I didn't really start this thread for a discussion or debate. I was merely frustrated because I screwed something up in the code and it took me a while to get it work again. I just needed to vent after that. Anyway, I understand the need for standards and I appreciate the work that you guys have put into this project.
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
- I really hate the fact that each line is 76 chars or less. I really don't know who benefits from this, but it makes the code really hard to read when I have to read 4 lines of code to see the control statement of a for() loop. Oh, so you'd rather have the rest of us scroll left and right all the time or experience the wonders of word wrap in code? 80 columns is, like it or not, still the default width for many things, including terminals. This means that using a few columns less than this (72-76) makes things a lot easier if you get stuck editing on an (admittedly somewhat brain-damaged) 80-column system and slightly easier on systems where you can resize windows and such but don't need to because almost everyone stays within 80 columns.
Also, splitting code onto several lines improves legibility in a complex case. If you have a for statement that (minus body) exceeds 80 characters, splitting it into parts makes sense.
- I really hate it when functions are used as arguments for other functions. This complaint coupled with the first one makes me wonder what the hell is going on in this code. I do this too, but not this often. This is probably a helpful optimization trick for older computers and the 3DO, but we're running quad-Xeon 200.4 GHz machines with hyperthreading and 256 GB RAM. We don't need this anymore.
This is not really optimisation; it's a way to make the code simpler. UQM mostly uses function pointer to allow code common to several contexts to call context-specific code. For example, the ship-handling code can call the Pkunk firing routines when processing a Fury and the Yehat firing routines when processing a Terminator without going through an insane amount of conditionals that choose the right routine. This is similar to the way in which you use subclasses in object-oriented languages (in fact, this aspect of OO is often implemented roughly like this).
Suggest an alternative approach that doesn't sacrifice legibility and performance (which is often important in games) and I can take this complaint more seriously.
- I really hate the lack of '{' and '}' in the code. I know if there's only one line of code after a for() loop or an if() statement, you don't need them. But when you couple this with the other two complaints, you have ultra unreadable code. And there really is no benefit to leave them out.
Leaving out curly braces around single statements saves space, which allows you to see more at a time, without sacrificing any of the visual cues connected to positioning; experienced programmers tend to use indentation instead of braces to find block structure.
If you can actually read the code in that format, more power to you, but it is just frying my brain. Anyway, now that that's out of my system, I will shut up now and get back to work.. In short, the code is the way most of us like it; changing it the way you like it would make it a lot harder to read for the rest of us.
|
|
|
Logged
|
|
|
|
harth1026
*Many bubbles*
Offline
Gender:
Posts: 142
|
I would debate this and give good reasons for my complaints, but as Meep-eep says, a discussion like this is pointless. We all have our own preferences so you'd probably wouldn't like my reasons anyway. The fact that this code doesn't meet my standards simply means that I have to just deal with it if I intend to share my finished product with the rest of your guys.
|
|
|
Logged
|
|
|
|
|
Pages: [1]
|
|
|
|
|