Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualachild

Posted 21 June 2013 - 02:15 PM

It needs to be in the implementation too.

 

May I give a small piece of advice, based on 15+ years writing code? What you're doing, making things const correct, some will argue it is a waste and even const itself is bad, others will argue it is good and makes it safer. That is a matter of opinion, both sides having reasonable arguments, but if you feel it makes it better and safer for the way you program, then hey it's probably a good idea.

 

However, this can easily become a thing where you start renaming all your variables/functions/macros/etc EVERYWHERE to conform to some standard way of naming things.

 

At first, this seems good, so things are consistent, and also once you have decided to do so it is easy to get OCD and require it everywhere. However, the problem is that if this happens to you, down the road, you will inevitably change, again, how you feel things should be named, for clarity. Then what, redo all your source code again? But now there are 100s of files instead of 10s. And so on.

 

One of the best things I learned on this topic was to simply work on the file that needs worked on, and keep it consistent with how it already is. If a file uses a naming convention where all variables are camelCase, stay with it so the file is consistent. If another file uses CamelCase, because you changed your mind one day on what looks better, use it... on that file, but not on the first one. Otherwise you will drive yourself crazy as your style and preferences change. Consistency doesn't have to be project wide when it comes to arbitrary choices like this (I'm not really talking about safety or smart design here, just style preferences), in fact it will be impossible once you start introducing third party libraries with their own styles. But, it should be consistent within a same source file. Now you won't go crazy.

 

I realize that is not what you are addressing here... but from experience I can say how easy it is to become that, so you might as well get the advice now.

 

[edit] That is what I am talking about, what is mentioned in the next post. Naming conventions are a good example. Keep it consistent within a file. And yes, if you prefer warts on your names, probably rAge for a reference versus pAge for a pointer, or you know, whatever you like.


#2achild

Posted 21 June 2013 - 02:12 PM

It needs to be in the implementation too.

 

May I give a small piece of advice, based on 15+ years writing code? What you're doing, making things const correct, some will argue it is a waste and even const itself is bad, others will argue it is good and makes it safer. That is a matter of opinion, both sides having reasonable arguments, but if you feel it makes it better and safer for the way you program, then hey it's probably a good idea.

 

However, this can easily become a thing where you start renaming all your variables/functions/macros/etc EVERYWHERE to conform to some standard way of naming things.

 

At first, this seems good, so things are consistent, and also once you have decided to do so it is easy to get OCD and require it everywhere. However, the problem is that if this happens to you, down the road, you will inevitably change, again, how you feel things should be named, for clarity. Then what, redo all your source code again? But now there are 100s of files instead of 10s. And so on.

 

One of the best things I learned on this topic was to simply work on the file that needs worked on, and keep it consistent with how it already is. If a file uses a naming convention where all variables are camelCase, stay with it so the file is consistent. If another file uses CamelCase, because you changed your mind one day on what looks better, use it... on that file, but not on the first one. Otherwise you will drive yourself crazy as your style and preferences change. Consistency doesn't have to be project wide when it comes to arbitrary choices like this (I'm not really talking about safety or smart design here, just style preferences), in fact it will be impossible once you start introducing third party libraries with their own styles. But, it should be consistent within a same source file. Now you won't go crazy.

 

I realize that is not what you are addressing here... but from experience I can say how easy it is to become that, so you might as well get the advice now.


#1achild

Posted 21 June 2013 - 02:11 PM

It needs to be in the implementation too.

 

May I give a small piece of advice, based on 15+ years writing code? What you're doing, making things const correct, some will argue it is a waste and even const itself is bad, others will argue it is good and makes it safer. That is a matter of opinion, but if you feel it makes it better, then hey maybe it's a good idea.

 

However, this can easily become a thing where you start renaming all your variables/functions/macros/etc EVERYWHERE to conform to some standard way of naming things.

 

At first, this seems good, so things are consistent, and also once you have decided to do so it is easy to get OCD and require it everywhere. However, the problem is that if this happens to you, down the road, you will inevitably change, again, how you feel things should be named, for clarity. Then what, redo all your source code again? But now there are 100s of files instead of 10s. And so on.

 

One of the best things I learned on this topic was to simply work on the file that needs worked on, and keep it consistent with how it already is. If a file uses a naming convention where all variables are camelCase, stay with it so the file is consistent. If another file uses CamelCase, because you changed your mind one day on what looks better, use it... on that file, but not on the first one. Otherwise you will drive yourself crazy as your style and preferences change. Consistency doesn't have to be project wide when it comes to arbitrary choices like this (I'm not really talking about safety or smart design here, just style preferences), in fact it will be impossible once you start introducing third party libraries with their own styles. But, it should be consistent within a same source file. Now you won't go crazy.

 

I realize that is not what you are addressing here... but from experience I can say how easy it is to become that, so you might as well get the advice now.


PARTNERS