Re: string parsing crashes
Posted: Sat Oct 02, 2010 11:24 am
1) opening/closing braces?
I prefer putting them on a new line. It helps with alignment of code blocks in my opinion.
2) spacing between parens and parameters for declarations and calls: this is what my current dev team uses in our code.
method signatures: space between the method name and first paren.
method call:
3) single operation if statement
a) For consistency I add the braces around the operation.
b) braces should be on new line for consistency
4) indentation:
4 spaces. This is common in most modern editors (ie Visual Studio, Eclipse, etc ). It also helps with readability IMO.
5) variable naming
a) camelcase
b) no strong opinion here, just that they are descriptive and consistent.
6)max nest block depth
anything nest more than 3 levels seems to scream for refactoring
7) line size limit
Nothing concrete. We all have higher res screens these days, so restricting to something like 80 chars is a bit much. However, something that forces the reader to scroll over three pages worth is too long.
8) variable /method declaration
h files
private, protected,public > Attributes then methods > And alphabetical order inside those: wololo
cpp files
they should be grouped by scope and function as well as alphabetized. Yes modern editors are smarter about it, but visually our minds process things quicker with some order.
** variable and method names should be descriptive. Having 1 or 2 character variable names my make typing easier, but we all are using smart editors right?
9)
* Comments around methods describing what they do unless utterly simple would be extremely useful. Especially for those of us (noobs and experienced) trying to understand the code. A line here or there goes a long way.
* First class representation of data. If there is information that floats around via strings, integers, etc that can be described by encapsulating it into an object, we should do so. We shouldn't try to infer meaning by coding around it. This may be a combination of creating new classes or refactoring old ones to form new objects. Just because data is currently stored in a particular way now, doesn't mean that it is set in stone. Requirements may change or new concepts may conflict with the current representation of the data.
* I find the use of Macros a little hackish and impossible to truly debug since they are not part of the active code. I would use them sparingly if at all. I would also want them to be very simple like SAFE_DELETE. Anything more invites possibilities for buggy code down the line.
* I tend to think header files should just be header files and not contain any implementation code at all. I understand that there may be some supposed performance improvements but I think having the ability to debug more important. Again, if one must inline, keep it to something very simple like getX() returns X without any processing
* We should also be careful not to have methods do more than what they seem to do. Methods should be clear in their contract with the calling code what is going to change. if I pass in two parameters to a getter method, neither of the params should be returned modified. An accessor is a read only operation, otherwise the design is flawed.
* single return point in a method is a good idea. My team and I try to enforce this. It may seem obtuse, but it guarantees that there is only one way out of a method. I've found that it helps with the flow of the method.
* I personally like to dereference variables before I put them into a conditional. It helps with keeping line size smaller and debugging. I've noticed VS doesn't always do the right thing when you hover over a pointer of a pointer from time to time for information. This way will allow you to put a break point at the conditional and see what it is trying to evaluate.
So code like this :
becomes
of course you'd want to put in guards where appropriate to catch and deal with error conditions.
I prefer putting them on a new line. It helps with alignment of code blocks in my opinion.
2) spacing between parens and parameters for declarations and calls: this is what my current dev team uses in our code.
method signatures: space between the method name and first paren.
Code: Select all
void methodA (string param1, string param2)
Code: Select all
this.methodA( "foo", "bar" );
a) For consistency I add the braces around the operation.
b) braces should be on new line for consistency
4) indentation:
4 spaces. This is common in most modern editors (ie Visual Studio, Eclipse, etc ). It also helps with readability IMO.
5) variable naming
a) camelcase
b) no strong opinion here, just that they are descriptive and consistent.
6)max nest block depth
anything nest more than 3 levels seems to scream for refactoring
7) line size limit
Nothing concrete. We all have higher res screens these days, so restricting to something like 80 chars is a bit much. However, something that forces the reader to scroll over three pages worth is too long.
8) variable /method declaration
h files
private, protected,public > Attributes then methods > And alphabetical order inside those: wololo
cpp files
they should be grouped by scope and function as well as alphabetized. Yes modern editors are smarter about it, but visually our minds process things quicker with some order.
** variable and method names should be descriptive. Having 1 or 2 character variable names my make typing easier, but we all are using smart editors right?
9)
* Comments around methods describing what they do unless utterly simple would be extremely useful. Especially for those of us (noobs and experienced) trying to understand the code. A line here or there goes a long way.
* First class representation of data. If there is information that floats around via strings, integers, etc that can be described by encapsulating it into an object, we should do so. We shouldn't try to infer meaning by coding around it. This may be a combination of creating new classes or refactoring old ones to form new objects. Just because data is currently stored in a particular way now, doesn't mean that it is set in stone. Requirements may change or new concepts may conflict with the current representation of the data.
* I find the use of Macros a little hackish and impossible to truly debug since they are not part of the active code. I would use them sparingly if at all. I would also want them to be very simple like SAFE_DELETE. Anything more invites possibilities for buggy code down the line.
* I tend to think header files should just be header files and not contain any implementation code at all. I understand that there may be some supposed performance improvements but I think having the ability to debug more important. Again, if one must inline, keep it to something very simple like getX() returns X without any processing
* We should also be careful not to have methods do more than what they seem to do. Methods should be clear in their contract with the calling code what is going to change. if I pass in two parameters to a getter method, neither of the params should be returned modified. An accessor is a read only operation, otherwise the design is flawed.
* single return point in a method is a good idea. My team and I try to enforce this. It may seem obtuse, but it guarantees that there is only one way out of a method. I've found that it helps with the flow of the method.
* I personally like to dereference variables before I put them into a conditional. It helps with keeping line size smaller and debugging. I've noticed VS doesn't always do the right thing when you hover over a pointer of a pointer from time to time for information. This way will allow you to put a break point at the conditional and see what it is trying to evaluate.
So code like this :
Code: Select all
if ( a->card->previous )
{
// do something
}
Code: Select all
object obj = a->card;
if ( card->previous )
....