I'll see your curly braces & raise you a variable naming convention
-
Hmm, on my keyboard Caps also need a double keypress ;P
Mircea
True that, but one hand remains on the letter portion of the keyboard. I find it easier, also more compact. Though snake_case helps understanding.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
True that, but one hand remains on the letter portion of the keyboard. I find it easier, also more compact. Though snake_case helps understanding.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
I know I'm not going to win this argument but on my keyboard, underscore is right above the P. I promise I'm not going to continue this argument :laugh:
Mircea
-
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^]. -
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^].In[Case]
PartsBin an Electronics Part Organizer - An updated version available! JaxCoder.com
-
Programs should be read as books. What would you prefer, aBookThatIsTypesetInLongWordsAlmostLikeGerman, or a_more_relaxed_one_that_leaves_spaces_between_words? PS: Is it St. Sterile de Bates Day today?
Mircea
-
I reject the premise of the question.
-
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^].PascaleCase
-
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^].In my first 10-15 years of programming, hardcopy printouts were still common. Both my university and my first employer used a printer model placing the underscore so low that it almost hit the top of the characters on the line below; you certainly didn't see it as tying two characters together. In a listing, a name with underscores looked like several space separated words. For variables starting / ending with an underscore, the underscore was easily overlooked. This could at times be really confusing. So I came to strongly dislike underscores in identifiers. If you really wanted to underscore a text line for emphasis, like in a header, these printers were fine - they didn't clutter up the text. Other printers, placing the underscore at the character baseline, were not suitable for underscoring. E.g. an underscored h would be very similar to a b, an underscored n was close to an o. So for emphasizing text, our printers were great, but not for underscore used as a printable character in an identifier.
-
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^]. -
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^].I pretty much do whatever strikes my fancy at the moment, throwing structure, conventions, and consistency to the wind. I find that adopting a care-free attitude to coding makes for a more interesting and fun time while testing and debugging my code in Production.
-
I know I'm not going to win this argument but on my keyboard, underscore is right above the P. I promise I'm not going to continue this argument :laugh:
Mircea
Another reason that made me dislike underscores (the the first one is hardcopy readability): Although you are right about upper case also being a double stroke, both the shift and the letter have identical positions on all keyboards, and you can keep your hands in the same position (as long as you have learned to use your left pinky for the shift key). If you switch between different keyboards - especially keyboards adapted to different languages - punctuation and special characters such as underscore jumps all over the place. It took a few years to define a Norwegian standard placement for all those new characters that came with PCs, unknown on traditional typewriters, so if I dig up my oldest keyboards, even on Norwegian keyboards, they jump around. Using a Norwegian keyboard at home, a US English one at the office, and sometimes some machinery with its own keyboard layout, can be very frustrating. Nowadays, on a Norwegian keyboard, underscore is shift-hyphen, the rightmost key in the bottom row, next to right shift. You have to move your right hand three-quarters off the keyboard to hit it. (That also goes for hyphen, even if it is un-shifted.)
-
Another reason that made me dislike underscores (the the first one is hardcopy readability): Although you are right about upper case also being a double stroke, both the shift and the letter have identical positions on all keyboards, and you can keep your hands in the same position (as long as you have learned to use your left pinky for the shift key). If you switch between different keyboards - especially keyboards adapted to different languages - punctuation and special characters such as underscore jumps all over the place. It took a few years to define a Norwegian standard placement for all those new characters that came with PCs, unknown on traditional typewriters, so if I dig up my oldest keyboards, even on Norwegian keyboards, they jump around. Using a Norwegian keyboard at home, a US English one at the office, and sometimes some machinery with its own keyboard layout, can be very frustrating. Nowadays, on a Norwegian keyboard, underscore is shift-hyphen, the rightmost key in the bottom row, next to right shift. You have to move your right hand three-quarters off the keyboard to hit it. (That also goes for hyphen, even if it is un-shifted.)
trønderen wrote:
to define a Norwegian standard placement for all those new characters
You, guys have too many characters in your language! Just get rid of those! :laugh: (says he, whose mother tongue has 5 extra characters... or 10 if you count the caps form).
Mircea
-
trønderen wrote:
to define a Norwegian standard placement for all those new characters
You, guys have too many characters in your language! Just get rid of those! :laugh: (says he, whose mother tongue has 5 extra characters... or 10 if you count the caps form).
Mircea
-
In my first 10-15 years of programming, hardcopy printouts were still common. Both my university and my first employer used a printer model placing the underscore so low that it almost hit the top of the characters on the line below; you certainly didn't see it as tying two characters together. In a listing, a name with underscores looked like several space separated words. For variables starting / ending with an underscore, the underscore was easily overlooked. This could at times be really confusing. So I came to strongly dislike underscores in identifiers. If you really wanted to underscore a text line for emphasis, like in a header, these printers were fine - they didn't clutter up the text. Other printers, placing the underscore at the character baseline, were not suitable for underscoring. E.g. an underscored h would be very similar to a b, an underscored n was close to an o. So for emphasizing text, our printers were great, but not for underscore used as a printable character in an identifier.
Great point about printers and the challenges of underscores. Thanks for sharing. This is also the reason we used to like Hungarian notation so much back then too. We did "offline" code reviews where we sat around a table and looked at code print-outs. Hungarian made sense because you could be a couple pages down and still know the type without looking back up at the declaration. :thumbsup: Of course, there was no intellisense back then either so... These kids don't know what they got!!! :rolleyes:
-
I use pascal case in .NET, camel case in JS, and snake case in my libraries in C++.
To err is human. Fortune favors the monsters.
-
wow! you use snake_case in C++? I only use snake_case in Rust bec I'm forced to. (oldish c/c++ dev here).
particularly for my libraries. I also tend to make heavy use of Generic Programming and thus templates, and so my libraries tend to be very STLish as it is. Consequently, I tend to follow STL patterns.
To err is human. Fortune favors the monsters.
-
particularly for my libraries. I also tend to make heavy use of Generic Programming and thus templates, and so my libraries tend to be very STLish as it is. Consequently, I tend to follow STL patterns.
To err is human. Fortune favors the monsters.
-
I pretty much do whatever strikes my fancy at the moment, throwing structure, conventions, and consistency to the wind. I find that adopting a care-free attitude to coding makes for a more interesting and fun time while testing and debugging my code in Production.
-
So which type of convention do you use when naming variables with multiple words? * camelCase * PascalCase * snake_case // Rust requires this for variable, function and struct member names and the compiler will warn (gripe at you) if you use other. I really like Rust, but this drives me crazy because it is YAC (Yet Another Convention) Back in C++ & C# I always used
PascalCaseThen in recent years JavaScript has effected my mind and I use a lot ofcamelCasethese days. Kotlin (Android dev) & Swift (iOS dev) seem to use camelCase too. So it becoming kind of a standard. How about you? See more here[^].I'm a solo dev and as such have complete autonomy to do as I please. It's funny that it has changed through the years as IDEs/autocomplete have gotten better, and my eyesight has gotten worse! :laugh: In the beginning, I followed the way I was taught at uni, which was either scopeTypeName for public/global or typeName for locals. Back then before IDEs got smarter, I also used very short variable names. As time wore on and my eyesight got worse, I started to favor snake_case_descriptive_names so that it was easier for me to read and understand. Additionally, IDEs had improved such that long names weren't an issue as far as typing and type recognition while reading/debugging. As for generic objects like iterators, indexes, database objects (connections, datatables, readers, etc.) I have a stock set that I have used for 20+ years. IMHO, these are distinctive enough as to basically serve as a digital fingerprint. Currently, I'm the only on working on my code, but I realize that may not always be the case. I'd like to think that between descriptive variable name, my shorthand, and sparse commenting, that the next poor chap who sees it can understand what this mess actually does! :laugh: Regarding curly braces, when I have to use them, I like the opening brace on a new line with everything indented between.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Ahh...never used much STL stuff because I (oddly) took up C# (in 2000/2001 very early) & that was when STL was coming on more strongly. My loss / lack of experience.
I don't use it a lot because it doesn't handle IoT very well without custom allocators and such, and even then it is heavy on little allocs and deallocs. I do study it though, because I believe in generic programming as a concept, when it comes to C++. If you aren't coding with GP, you aren't using the most powerful, flexible feature of C++. Templates really are where it's at with this language. They are first class, and if they aren't first class in your code, you're probably not using it to its full potential.
To err is human. Fortune favors the monsters.
