The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
October 16, 2024, 04:22:44 am
Home Help Search Login Register
News: Celebrating 30 years of Star Control 2 - The Ur-Quan Masters

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  Source Code Format
« previous next »
Pages: [1] Print
Author Topic: Source Code Format  (Read 1922 times)
harth1026
*Many bubbles*
***
Offline Offline

Gender: Male
Posts: 142



View Profile WWW
Source Code Format
« on: May 18, 2005, 01:34:28 am »

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
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Source Code Format
« Reply #1 on: May 18, 2005, 03:41:47 pm »

From the file "Contributing":
Quote
Follow the coding style of the existing source. You don't have to like it, we don't even always do, but we've accepted this as our standard. The main reason is that this is very close to the original style. Trying to start a discussion about the standard is pointless and is definately NOT appreciated.

I would have some specific comments to your points, some agreeing, some disagreeing, but such a discussion is pointless, and I'm not going to waste any words on this.
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
harth1026
*Many bubbles*
***
Offline Offline

Gender: Male
Posts: 142



View Profile WWW
Re: Source Code Format
« Reply #2 on: May 18, 2005, 07:25:49 pm »

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 Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Source Code Format
« Reply #3 on: May 18, 2005, 07:55:25 pm »

Quote
- 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.

Quote
- 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.

Quote
- 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.

Quote
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

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
harth1026
*Many bubbles*
***
Offline Offline

Gender: Male
Posts: 142



View Profile WWW
Re: Source Code Format
« Reply #4 on: May 18, 2005, 08:18:30 pm »

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
Zeep-Eeep
Enlightened
*****
Offline Offline

Gender: Male
Posts: 917


Good Grief


View Profile WWW
Re: Source Code Format
« Reply #5 on: May 22, 2005, 08:39:42 am »

It's a well documented problem that most coders
do not like the coding style of other coders. Ask
five programmers to code "Hello World" in C and
you'll get five different results.
After a while most of us learn to live with it
and develop a skill for reading other people's
messes....er coding styles.
Logged

What sound does a penguin make?
Pages: [1] Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!