Refining code to be packaged with mathematical programming language. Criticize!!

[Kp]

strcpy can only copy one string from one place to another.  sprintf is far more versatile.  You should prefer strcpy when it's sufficient, and prefer length-checked forms over non-length-checked forms in any case.  Also, for what you're doing, you don't need to copy the string before working on it.

[Rule]

Also, for what you're doing, you don't need to copy the string before working on it.

Indeed.  Thanks for all the help. .

[Maddox]

I use kernel style coding when I program in C on Linux.  Makes everything look nice and consistent with the API.

Here are some pointers...

typedefs -> Do not use them for things like structs, just integer types.  Do not use them to hide a pointer, ie PVOID.

brackets -> New line for functions, same line for everything else.  Use bracks on all if statements, even if they are 1 line.

case -> everything should be short, lower case, and seperated with underscores if need be.  ie foo_bar.  DO NOT USE HUNGARIAN NOTATION.

! -> only use ! on boolean functions.

NULL/0 -> NULL for pointers, and 0 for integers.

variables -> declare them all at the beginning.

[Rule]

case -> everything should be short, lower case, and seperated with underscores if need be.  ie foo_bar.  DO NOT USE HUNGARIAN NOTATION.

Thanks for the advice, but what is so alarming about HUNGARIAN NOTATION?

Hmm, also, sometimes I think the "everything should be short" idea gets taken much too far and things become so unclear.  For example, lets say I want to think of a variable that stands for "assignment list pointer".  alistp is preferable imo to the possible, alp, lp, alsp variants.

[MyndFyre]

case -> everything should be short, lower case, and seperated with underscores if need be.  ie foo_bar.  DO NOT USE HUNGARIAN NOTATION.

Thanks for the advice, but what is so alarming about HUNGARIAN NOTATION?

Hmm, also, sometimes I think the "everything should be short" idea gets taken much too far and things become so unclear.  For example, lets say I want to think of a variable that stands for "assignment list pointer".  alistp is preferable imo to the possible, alp, lp, alsp variants.

I disagree with Maddox about hungarian notation.  It's not nearly such a panicky thing to concern oneself with.

As he said, that's what he does to be consistent with the Linux API.

For variable naming, when using classes, I always prefix member variables (instance) with m_ and static variables (class) with s_.  If something could potentially be confusing, I will occasionally prefix the name of the variable with hungarian notation.  For example, if I have a hashtable containing a list of friends by their GUIDs and an arraylist, I might have m_alFriends and m_htFriendsByGuid.

I tend to believe his hardline stance against hungarian notation has developed because of things he's read about it.  Usually, arguments against hungarian notation stem from the "we've got good IDEs now that can identify variable typing for us" argument.  I've never found something particularly compelling, except in the argument of a design-code-revision argument (for example, if I wanted to change it from a hashtable to a dictionary in the previous example).  Of course, now that my IDE supports full-project refactoring, all I need to do is rename the identifier and it will update all the relevant files, and since I use good encapsulation practices, hungarian notation never appears outside of class files.

[Maddox]

case -> everything should be short, lower case, and seperated with underscores if need be.  ie foo_bar.  DO NOT USE HUNGARIAN NOTATION.

Thanks for the advice, but what is so alarming about HUNGARIAN NOTATION?

Hmm, also, sometimes I think the "everything should be short" idea gets taken much too far and things become so unclear.  For example, lets say I want to think of a variable that stands for "assignment list pointer".  alistp is preferable imo to the possible, alp, lp, alsp variants.

Hungarian notation is useless under Linux.  It's only there in Windows because MS made a mess of the windows API and now the types of variables are unclear when programming with it.  They've cleaned it up a lot in WinFX.  In general, you should be able to tell what type of variable it is from context.  This is why you assign _t's to typedefs.

[Maddox]

case -> everything should be short, lower case, and seperated with underscores if need be.  ie foo_bar.  DO NOT USE HUNGARIAN NOTATION.

Thanks for the advice, but what is so alarming about HUNGARIAN NOTATION?

Hmm, also, sometimes I think the "everything should be short" idea gets taken much too far and things become so unclear.  For example, lets say I want to think of a variable that stands for "assignment list pointer".  alistp is preferable imo to the possible, alp, lp, alsp variants.

I disagree with Maddox about hungarian notation.  It's not nearly such a panicky thing to concern oneself with.

As he said, that's what he does to be consistent with the Linux API.

For variable naming, when using classes, I always prefix member variables (instance) with m_ and static variables (class) with s_.  If something could potentially be confusing, I will occasionally prefix the name of the variable with hungarian notation.  For example, if I have a hashtable containing a list of friends by their GUIDs and an arraylist, I might have m_alFriends and m_htFriendsByGuid.

I tend to believe his hardline stance against hungarian notation has developed because of things he's read about it.  Usually, arguments against hungarian notation stem from the "we've got good IDEs now that can identify variable typing for us" argument.  I've never found something particularly compelling, except in the argument of a design-code-revision argument (for example, if I wanted to change it from a hashtable to a dictionary in the previous example).  Of course, now that my IDE supports full-project refactoring, all I need to do is rename the identifier and it will update all the relevant files, and since I use good encapsulation practices, hungarian notation never appears outside of class files.

I said I use this style when I program in C on Linux.  Maybe you don't know, but C does not have classes.