Jump to content

  • Log In with Google      Sign In   
  • Create Account

00Kevin

Member Since 12 Oct 2005
Offline Last Active Jul 21 2016 12:20 PM

Posts I've Made

In Topic: Do you usually prefix your classes with the letter 'C' or something e...

09 June 2016 - 12:38 PM

btw,  you gotta love coders who, before they even begin to make modifications, waste half the day or more changing the coding style.    

 

One guy I worked with changed all the database commands to upper case.   I was like really?

 

As for camelCase or PascalStyle,  my pinky has been brutalized on this shift key because you! 


In Topic: Do you usually prefix your classes with the letter 'C' or something e...

09 June 2016 - 12:32 PM

 

Yes, if you want good code style, you must make classes as CMyClass and interfaces as IMyClassInterface

This is a subjective opinion presented as an objective fact.
...and it's not even a popular opinion.  

Naming classes from lowercase is bad practice, and using "_" in defining is bad style(for readeable). You must start every letter from uppercase and not use "_".

Lowercase with underscores is actually the most 'official' style that C++ has, as it's used by the standard library (and many other projects).
The people who choose it would say the opposite opinion: that CamelCase is bad style and makes code less readable..

 

I work with one programmer who hates underscores.   So we all try to add a few extra once and a while just to hear him scream "I hate f**king underscores!'.    


In Topic: Do you usually prefix your classes with the letter 'C' or something e...

09 June 2016 - 12:28 PM

 

 

Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.


The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.

 

A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals.  The compiler can then help you by catching incorrect usage.  In an ideal world C++ would have had these requirements from the outset.

 

this, a thousand times this (pun absolutely intended). I sometimes wish c++ had gone the same route as python or rust with an explicit self/this parameter. which could also enable things like templates based on the reference qualifiers of the object.

 

 

shortly after the wheel we invented find/replace and yet things still get missed.  


In Topic: Do you usually prefix your classes with the letter 'C' or something e...

09 June 2016 - 12:23 PM

 

There are no strict standards for success.


Actually there is. Be consistent, at least in your own codebase. If I know something is called a foo bar I should be able to deduce its name without having to check on which day it was written. FooBar, CFooBar, TFooBar, foo_bar, ... are all somehow acceptable provided they follow a clear pattern.

I still wished C or T prefixes would remain in the dustbin of history though.

 

 

That doesn't happen. 

 

The point I'm making is that readability (for the next guy) is far more important than a bunch of strict coding styles that are largely subjective and change over time. 

 

I'm talking from years of experience developing large enterprise level systems that evolve.  Code bases developed by multiple developers often contain mixed styles. That's the reality regardless of how idealistic you are.    As programmers we deal with what IS and not with what should be.  The fact is most successful business systems contain mixed conventions and poorly written code anyway .  So unless you are the sole developer for the entire life of an application, there's no sense in being strict in regards to programming style.  For success, focus on the architecture of your product, which is the true measure of success,  and don't be guilty of using meaningless notations. 

 

Now, I'm not trying to write a book here or publish a thesis to become famous, I'm just telling you the way it really is.   With that said, I'm frequently reminded of all those jokers in my class that couldn't code very well.   I found out the hard way that they are busy writing endless lines of bad code for us all.  :)  So in the grand scheme of things, stylistic conventions are the least of our concerns as programmers. 


In Topic: Do you usually prefix your classes with the letter 'C' or something e...

08 June 2016 - 10:20 AM

This reminds me that many years ago it was also common to use the prefix letter 'T' for the class definition...    I wonder what happened to that.    

And the prefix 'C'?  don't remind me the horror that is MFC.  

 

 

With that said, after working on a several large business system across many different languages I hate prefix / Hungarian notation with a passion.   

 

I find that coding conventions (especially prefixes) are rarely enforced, change over time, and are usually only grudgingly accepted (if at all) by subsequent developers who inherit your work.   In the end, everyone tries to adopt their own conventions and the code base becomes a complete mess.    

 

IMO, just make your code readable.  There are no strict standards for success.   In fact, sometimes the variable name 'i' is more readable than a long description and sometimes it isn't.  If you write your code for other people to read then you'll be successful.   If you code for yourself and include your own bullshit or the latest fad conventions you won't.  


PARTNERS