[quote]I thought I was the only person who thought the open bracket after the declaration looks stupid.
[/quote]
No there are a couple of you
Yeah, one more here
Ive beeing learning and looking at more c++ lately, and the styles have really rubed off on me. Like next line braces, and more use of abbrivated variable/class names. But still havnāt picked up hungarian notation, which is so common.
I think using abbrivations can be overused, but there are some cases where it works. Like when the meaning is clear, and its used all over the place, like vectors.
Regularly i thank the kind souls that gave us eclipes, and its code formater. I never would have been able to make an inner listener with out them.
While we are talking formating, what is style comments do you like?
Im thinking more for personal readability than java doc compliance.
Jumping in late, butā¦
I donāt care for non-aligned braces at all. I WANT to see my code blocks, and virtually every editor I have used does some form of highlighting if you put the cursor at one brace or another (even vi does this, just hit % and it takes you to its pair).
As for spacing, Iām a spacing freak. I prefer spaces before parenthesis, except for class cast like this:
temp = (Image) vImages.next();
if ( temp != null )
{
// Do something here
}
And no space when thereās nothing between the ().
Comments? What are those??? evil grin (For me, I just like straight javadoc, or a // one liner for explanation.)
Further question:
who likes their variables aligned, and what convention do you use?
int x;
Object y;
DataBuffer z;
I donāt align the variables, that seems a bit excessive, but I am quite careful to always declare the same types together.
I find that I donāt usually need much more than the javadoc comments- as long as you keep methods short, splitting the really long ones up if necessary, you can usually work out what is going on. And For some reason I find going back through my own Javadocs quite satisfying. I donāt know why.
I sometimes align variables that are related, with spaces, so tab sizes donāt bugger them up. It depends on how different the ātypeā identifiers are in length too⦠if the variable name will get āhiddenā in a crevice I add spaces to pull it out. e.g. in:
MegaBlasterLevel level;
int score;
SuperDuperSpaceShip ship;
I would push āscoreā out to line up with ālevelā
[quote]Hey if we are talking coding conventions lets have a fight about the evils of misplaced parenthesis
I hate Sunās āstandardā way⦠I like my {} alignedā¦
if( blah )
{
woo(hoo);
}
Iāve seen some odd alternatives too⦠likeā¦
if( blah )
{
ew(yuk);
}
And if I had to name them, I would call them Floyd :D.
[/quote]
i used the 2nd style for some years. switched awhile ago to the first one, cuz it was much easier to type with textpad :>
if i had to name em, i would call em block-style A and block-style B. sounds cold and techie doesnt it? =)
āsunās wayā is called āhugging bracketsā (or summin like that)⦠dunno i hate it too
and names for other stuff⦠mhā¦
int bs = 0; //bonus sprite (-1 = level up | 0 = none | 1 = full fuel/health)
int bsX=666; //out of sight
int bsA=0; //animation (blink 0/1)
int bsY=60;
//explosion
int[][] exx=new int[MAX_STUFF][3]; //x,y,age
int ex=0;
//heli
int[][] hh=new int[MAX_STUFF][3]; //x,y,d
int h=0;
somewhat scary isnt it? :>
[quote][ā¦]
I would push āscoreā out to line up with ālevelā
[/quote]
it would look better but it wouldnt increase readability (imo).
g.fillRect(0, 0,640,60); //top
g.fillRect(0,420,640,60); //bottom
[...]
for(x=0;x<MAX_STUFF;x++)
{
pp [x][1]= 0; //move projectiles out of sight (-1 Y-shift)
exx[x][2]=62; //move explosions out of sight (<62 check)
hh [x][1]= 0; //move helis out of sight (=0 check)
}
in this two cases it makes more sense. u can read it much better, cuz the values wich have summin in common are next to each other.
btw that r parts from my highly ineffective 4k game, wich isnt finished yet :>
For what itās worth, I learned to like the āsunā way of brackets although I really hated it at first.
It makes the code more compact while keeping readability and sometimes even enhances it in case of larger functions (I like keeping an overview and I hate scrolling through code).
In fact I like the sun conventions in general.
I am with the āblockā crowd, much easier to read, esp. since I donāt use {'s for on-line ifs
if(b)
foe(x,y,z);
Mix that with the mis-aligned braces and things gets horribly complicated.
I align variables (both members and local).
I keep members at the beginning of the class and always prefix with ām_ā - statics are prefixed with g_ and static final (constants) are all caps. (simple data-classes with no code and public fields donāt have the m_)
I use i-prefix for integers (of all sizes), x for fixed point, f for floating points (float and double), a for arrays, v for vectors, s for strings. Other types are not prefixed. I occasionally stray from this (for example when using i, x, y, z etc. in loops and for local variables).
My vector class is an interface called Vec (and Vec2, Vec3 etc. for various impl.)
Upper-case first char in class names, lower case in methods and variables.
I donāt use the I and C prefix on Interfaces/classes commonly used in C++ as I donāt feel the need for that in Java (besides, my IDE clearly indicates which is what so I donāt need it).
Oh, and I prefer grey background in my editor. Comments in dark-grey so they donāt clutter the important part - the code ā¦
I do
if (b) foo(x,y,z);
Again, a lot more compact which makes the code generally easier to understand for me
[quote]Oh, and I prefer grey background in my editor
[/quote]
I prefer black girls. :
Ah well, itās all just a matter of personal taste and habit I suppose
Hi,
No one talked about labels
Iām used to name all of them deCadix, because of the French song http://membres.lycos.fr/chezthal/luismariano/labelledecadix.html
And for other variable names, I follow the Disney characters recommendations from this thread http://forum.java.sun.com/thread.jsp?forum=4&thread=341770. ;D