I object to this being parachuted in here. There was a long discussion about this subject, mostly disagreeing with the concept.IMHO Tutorials should only be posted here when there is a consensus supporting them....R
Thanks for explaining,Hungarian notiation (HN) is indeed one way to help people to understand code on the dataType level.I personally are not a great fan of it as the compiler will check on that level.HN does not help to understand code on architectual/design or requirements level which are imho far more important. The programmer should know WHY to use an uint32_t, or a volatile, static etc.After 12 months I have more problems wiyh why a certain algorithm was used, how the flow of information etc is, or how does it work at all. Yes it is still important to know what the datatypes of the variables are but these are often direct deducable from code.e.g. Serial.println(Age); // will print the Age, no matter if it was a string or numberAge = Age + 5; // clearly a nummeric typeAge = Age + "years" // bet it will be a StringYes HN would help in all those case, but it does not explain why e.g. 5 was added For me it is more important that people give a good descriptive name to the variables, classes and functions.Would you consider using Hungarian notiation also for functions?String strDetails = formatStudent(strSurname, strFirstName, szAge, szStudentNumber);==>String strDetails = strFormatStudent(strSurname, strFirstName, szAge, szStudentNumber);How do you handle HN for class class instances? And fields/methods of those classes?what is more readable?if (vkbeKeyBoardEvent.u16ErrorCode == u16ErrorTable[u8ErrorIndex]) ...orif (KeyBoardEvent.ErrorCode == ErrorTable[ErrorIndex]) ....// vkbe - volatile KeyBoardEvent, jus made that up ...There are similar style discussions about adding comments to code. Yes it helps people a lot if the comment explains the WHY of the code is written that way. Comment does not help if it just repeats the code, or worse it does not match the code anymore. Choosing good descriptive names for variables makes code readable.Serial.begin(9600); // open the serial port with 9600 baudone review laterSerial.begin(115200); // open the serial port with 9600 baudanother reviewSerial.begin(config.baudrate); // open the serial port with 9600 baudwhile it should just beSerial.begin(config.baudrate);Thanks for explaining
Age = Age + 5; // clearly a nummeric typeAge = Age + "years" // bet it will be a String
Wasn't Hungarian notation designed for C?But we're in C++ here.(I've asked for a moderator to move this to "General Discussion", because I don't see how it helps beginners, who struggle with datatypes as it is, without confusing them with how the variables should be named)
..because some of those other languages allow you to "add" an integer to a string, for example?(And because your software ends up looking like it was written by Microsoft in the 1990s, and nobody wants that )
Big woop.....that means the HN will indicate that doing so is allowed in that particular language.
...but makes porting the code (specifically the variable name) to a different language that much more difficult.
What is it with the coding nazis in here?
Bingo! Godwin's Law.Check out Torvalds' and Stroustrup's opinions on Hungarian. I think you'd better arguing for using a better IDE.
I object to this being parachuted in here. There was a long discussion about this subject, mostly disagreeing with the concept.IMHO Tutorials should only be posted here when there is a consensus supporting them.