private void updateCross () {
crossection = 0;
for (int i = 0; i < moduleGeometry.length; i++) {
for (int j = 0; j < moduleGeometry[0].length; j++) {
for (int k = 0; k < moduleGeometry[0][0].length; k++) {
crossection += moduleGeometry[j][k].getCrossSection();
}
}
}
}
private void fire() {
// Order of ships : First the assigned target, then
// the detected ones in order of detection. Sorting
// already done in detect method. For each ship, try
// to assign each weapon to fire at it.
if (targetShip != -1) {
fireAt(targetShip);
}
for (int i = 0; i < detectedShips.length; i++) {
if (detectedShips != -1) fireAt(detectedShips);
}
}
private void fireAt (int target) {
Vector3d forward = new Vector3d(Math.cos(myAngle), 0, Math.sin(myAngle));
Vector3d toTarget = new Vector3d(allShips[target].position.x - position.x, 0, allShips[target].position.z - position.z);
for (int i = 0; i < myGuns.length; i++) {
if (myGuns.canFire(forward, toTarget)) {
// TODO : May want to consider things like volley fire, etc - hence
// separate method for canFire and doFire.
myGuns.fireAt(allShips[target]);
}
}
}
🔒 Locked
Is my code readable?
Advertisement
Original Post
I sometimes wonder if my coding style is totally idiosuncratic, understandable only by me, or if I could give my code to someone else and have them read it. So I'm asking you to judge - do I need to change? Here's an example picked at random from the project I'm working on : [Edited by - King of Men on April 7, 2005 12:49:32 PM]
I'm no expert but your code looks fine to me. I don't like spaces after function names, for's, and if's but that's just my preference. I also prefer lining up the vertical curly braces but again, that's just my preference. [smile]
You code like a Linux programmer. Well, if you ignore the CamelCase, anyway.
I have no idea what updateCross is supposed to be doing, so maybe it could use a few more comments, but for the most part it looks good.
I have no idea what updateCross is supposed to be doing, so maybe it could use a few more comments, but for the most part it looks good.
I, on the other hand, prefer K&R style, so I'm glad your braces are on the same line as the if's, for's, and etc's :P
In response to kingnosis : I do my braces like that as well -- if the single statement is on the same line as the if, then I don't put them, but otherwise they're always there, which seems to be how KoM is doing it
For the stuff other than pointless formatting disputes, it looks good. Your variables seem to be consistantly named and sufficiently verbose. For the small functions, the names are reasonable hints at what they do, and the algorithms appear simple enough to not need more commenting. I couldn't tell you more without a larger sample that, for example, included the exposition of the public interface to the class and the associated comments.
In response to kingnosis : I do my braces like that as well -- if the single statement is on the same line as the if, then I don't put them, but otherwise they're always there, which seems to be how KoM is doing it
For the stuff other than pointless formatting disputes, it looks good. Your variables seem to be consistantly named and sufficiently verbose. For the small functions, the names are reasonable hints at what they do, and the algorithms appear simple enough to not need more commenting. I couldn't tell you more without a larger sample that, for example, included the exposition of the public interface to the class and the associated comments.
the only thing I'd change is this
That way it's easier to tell where the condition ends and the statement begins.
I also always use {}, even on one line ifs. It avoids this kinda problem
but that's just personal preference
if (detectedShips != -1) fireAt(detectedShips);// becomesif (detectedShips != -1) fireAt(detectedShips);That way it's easier to tell where the condition ends and the statement begins.
I also always use {}, even on one line ifs. It avoids this kinda problem
if (detectedShips != -1) identify(detectedShips);// oops this will always be called fireAt(detectedShips);but that's just personal preference
Quote:
Original post by Anonymous Poster Quote:Java programmer would be a better example, considering also how he allocates Vector3ds and never releases the memory. (I doubt Vector3d is a smart pointer)
Original post by smart_idiot
You code like a Linux programmer. Well, if you ignore the CamelCase, anyway.
Careful inspection reveals that the code is Java.
Or possibly C#.
Sometimes the '{' is out of view on smaller code windows (UltraEdit) when I have all the other windows open. Even then I sometimes overread the '{' at the end of the line.
Personally I favor always using '{}' and putting the '{' in a new line. IMHO makes it easyer to find the matching '}'.
Plus when the '()' and '{}' start to add up in complex ifs it helps when you format them in a way that is easy to read.
Personally I favor always using '{}' and putting the '{' in a new line. IMHO makes it easyer to find the matching '}'.
Plus when the '()' and '{}' start to add up in complex ifs it helps when you format them in a way that is easy to read.
I also like to put the { on the same line, because I think its more consistent with other brace types:
Whether a block is started or not can be seen from the indentation, at least it never happened to me that I overlooked the opening brace.
-Markus-
int simpleMethod() const { return m_x; }int complexMethod() const { return (m_x * m_x) + (m_y * m_y);}callMethod(arg1, arg2);callMethodWithAFarTooLongName( arg1, arg2);float value = plainArrayAccess[index];float value = nastyIndexCalculatedArrayAccess[ getDesiredIndex() + startingOffset - arrayBase];Whether a block is started or not can be seen from the indentation, at least it never happened to me that I overlooked the opening brace.
-Markus-
That whole issue about lining up (or not) of {}'s is a bit silly. We had a university lecturer who marked you DOWN if you didn't exactly follow his style [oh].
FWIW, I've come across the general convention that in Java you put { on the end of the line with the statment, indent all subsequent items in the block, and then close } on the same column as the initial statement started:
However, in C/C++ and pretty much every other language I've come across it seems to be convention to make the { and } start/finish at the same column:
I don't subscribe to language-bashing if I can help it, but it does seem to me that Java is the odd one out - wanting to do it it's own special way...
Bottom line is - being consistent is whats important [smile]. If you work for a big company (like I do) then coding standards documents will tell you which one to use (the 2nd example in my case)..
Jack
FWIW, I've come across the general convention that in Java you put { on the end of the line with the statment, indent all subsequent items in the block, and then close } on the same column as the initial statement started:
if( true ) { if( false ) { //This is never executed }}However, in C/C++ and pretty much every other language I've come across it seems to be convention to make the { and } start/finish at the same column:
if( true ){ if( false ) { //Same as above }}//OR:if( true ) { if( false ) { //Same again } }I don't subscribe to language-bashing if I can help it, but it does seem to me that Java is the odd one out - wanting to do it it's own special way...
Bottom line is - being consistent is whats important [smile]. If you work for a big company (like I do) then coding standards documents will tell you which one to use (the 2nd example in my case)..
Jack
Yup, consistency is important. I think the 'put the { on the same line' originated when most people programmed in 80x25 text mode terminals, but I might be wrong there. My personal style is camelBack notation, I think it works well :) Coding style is a kind of religion to many people tho.
Quote:
Original post by CloudNine
Yup, consistency is important. I think the 'put the { on the same line' originated when most people programmed in 80x25 text mode terminals, but I might be wrong there. My personal style is camelBack notation, I think it works well :) Coding style is a kind of religion to many people tho.
A lot the developers I work with still use mainframe 80x25 style programming/editing. They often tell me that:
IF ( X ¬= 10 ) THEN DO SAY "X is not 10"ENDshould be:
IF ( X ¬= 10 ) THEN DO SAY "X is not 10" ENDI do prefer their style, but I'd been programming in Java for a while before this and slipped into "Java style" formatting [smile]
Jack
Quote:
Original post by jollyjeffers Quote:
Original post by CloudNine
Yup, consistency is important. I think the 'put the { on the same line' originated when most people programmed in 80x25 text mode terminals, but I might be wrong there. My personal style is camelBack notation, I think it works well :) Coding style is a kind of religion to many people tho.
A lot the developers I work with still use mainframe 80x25 style programming/editing. They often tell me that:IF ( X ¬= 10 ) THEN DO SAY "X is not 10"END
should be:IF ( X ¬= 10 ) THEN DO SAY "X is not 10" END
I do prefer their style, but I'd been programming in Java for a while before this and slipped into "Java style" formatting [smile]
Jack
Out of interest, what are those developers programming?
Yup, looks good to me. As a matter of preference I prefer this style:
while(true)
{
//stuff
}
instead of while(true) {
//stuff
}
but that's only my preference and I don't really mind the other way.
while(true)
{
//stuff
}
instead of while(true) {
//stuff
}
but that's only my preference and I don't really mind the other way.
I hate
style, I'm almost ready to make some blue eyes for that...
But then again I code in C/C++, and VS higlights mathing braces. I like when they gets highlighted on same column...
Moreover
is in no way equivalent to:
if(stuff) {morestuff}style, I'm almost ready to make some blue eyes for that...
But then again I code in C/C++, and VS higlights mathing braces. I like when they gets highlighted on same column...
Moreover
#ifndef STUFF#define STUFF#endifis in no way equivalent to:
#ifndef STUFF #define STUFF#endif
Quote:
Original post by tolleyc
Personally, I usually put a comment after all my closing curly brackets.
Example:
for( int n = 0; n < 10; ++n ){ < do stuff > }// End for n
That way I know what is ending what, but thats just me. I don't know if anyone else does that.
We were required to at university or we lost marks [rolleyes]. I dropped it as soon as it wasn't marked. If you have a decent IDE (currently I'm using Eclipse more than VStudio) then it'll tend to highlight the scope of a given bracket/brace - I find that it be just as useful/easy...
Quote:
Original post by CloudNine
Out of interest, what are those developers programming?
That example was "REXX" a really old scripting language. It's really powerful, but amazingly simple - I learnt it in about 2-3hrs [grin]. However, the developers I referred to actually code in PL/X (an IBM owned derivative of PL/1), C and Assembly. It's more the fact that it's mainframe software that they're writing than the particular languages that require them to use 80x25 displays [smile]
Jack
Quote:
Original post by Promit Quote:
Original post by Anonymous Poster Quote:Java programmer would be a better example, considering also how he allocates Vector3ds and never releases the memory. (I doubt Vector3d is a smart pointer)
Original post by smart_idiot
You code like a Linux programmer. Well, if you ignore the CamelCase, anyway.
Careful inspection reveals that the code is Java.
Or possibly C#.
Wait, then in his post why does he say specifically [ code = "cpp" ] ? Wouldn't he do [code = "java" ] if it was Java?
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement