Author Topic: Suggestion on naming variables C  (Read 12761 times)

0 Members and 1 Guest are viewing this topic.

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2197
  • Country: nz
Re: Suggestion on naming variables C
« Reply #25 on: March 30, 2015, 04:37:03 am »
You dislike underscores of all things? I find snake_case to be significantly more legible than CamelCase.

I sort of a agree with you - underscores also plays nicer with acronyms in variable names - e.g. current_SATA_state vs CurrentSATAState.

I also really hate is people who drop vowels out of words, e.g. (FrgrndClr or BckgrndClr) - the days of 80 columns screens are long gone. :D
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9416
  • Country: my
  • reassessing directives...
Re: Suggestion on naming variables C
« Reply #26 on: March 30, 2015, 07:17:41 am »
I also really hate is people who drop vowels out of words, e.g. (FrgrndClr or BckgrndClr) - the days of 80 columns screens are long gone. :D
you havent done complex formula with those long name? trying to fit all in one line? try it sometime it can be fun... otoh trying to say "i" cannot be used as vars is like saying all algebraic symbols are wrong.
« Last Edit: March 30, 2015, 07:20:29 am by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2294
  • Country: gb
Re: Suggestion on naming variables C
« Reply #27 on: March 30, 2015, 08:38:31 am »
You dislike underscores of all things? I find snake_case to be significantly more legible than CamelCase.

I sort of a agree with you - underscores also plays nicer with acronyms in variable names - e.g. current_SATA_state vs CurrentSATAState.

Particularly annoying is when a variable has to hold a value in a particular unit e.g. something relevant to me would be optical power in milliwatts:

opticalPowerMw /* Not megawatts! */

If I'm working on a project that uses primarily camel case, then I'll add an underscore in this case as I can't stand the abused unit notation:

opticalPower_mW

I think far too much fuss is made over specific coding styles. For me consistency is more important than a particular style, I hate working on projects that have a mishmash of different styles.
« Last Edit: March 30, 2015, 08:41:04 am by mikerj »
 

Offline alexanderbrevig

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: no
  • Musician, programmer and EE hobbyist
    • alexanderbrevig.com
Re: Suggestion on naming variables C
« Reply #28 on: March 30, 2015, 08:51:54 am »
It should also be clear from the above that blindly saying "fuck hungarian notation" without understanding why it was used is just as incorrect as blindly using it.

The resource on why it's viable to say it (though not blindly) has already been posted. http://www.joelonsoftware.com/articles/Wrong.html

For me, naming a variable to indicate it's unsafe nature has nothing to do with hungarian notation, even though that may have been it's intention that's not its semantics any more. For me, this is just one of many best practices to follow.

[...]trying to say "i" cannot be used as vars is like saying all algebraic symbols are wrong.

A programmer that takes the time to make the potentially complex algorithm read well indicates that he understands the problem, understands the algorithm and care to help the next guy understand too.
I think it's OK to use algebraic symbols in code only if you include the formula in a comment above. If you've ever seen an undocumented FFT/convolver (phase netural EQ, impulse response filter etc) that only uses algebraic notation then you know what I'm getting at.

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4816
  • Country: gb
Re: Suggestion on naming variables C
« Reply #29 on: March 30, 2015, 09:55:36 am »
It should also be clear from the above that blindly saying "fuck hungarian notation" without understanding why it was used is just as incorrect as blindly using it.

The resource on why it's viable to say it (though not blindly) has already been posted. http://www.joelonsoftware.com/articles/Wrong.html

For me, naming a variable to indicate it's unsafe nature has nothing to do with hungarian notation, even though that may have been it's intention that's not its semantics any more. For me, this is just one of many best practices to follow.


Firstly, all you are citing is an opinion by someone else, it is not THE resource, it is A resource. How do you think we all managed before Joel came on the scene? We must've all been neanderthals. If you read what he has to say on it, he's essentially saying (rightly in my opinion) that Microsoft made a right old pig's ear of what was at the time fundamentally a good idea.

Secondly, HN isn't about indicating a variable's unsafe, it's about helping the programmer to help him/herself and make clear that the type is intended, not just slapped in there for no apparent reason, such as using an int64_t when an int8_t would do.

The next bit is a head scratcher, I've re-read it a couple of times, you seem to be suggesting that HN is now a "best practice" in your opinion, but before you were against it?

I should also add that as soon as I see the over-used expression "best practice" I hear alarm bells. It's a term often used far too frequently and lazily as a way of imposing something that is an opinion without having to justify it: it's saying to me if I don't do it your way then I am just wrong without you needing to supply any reason.

My point, to reiterate, is that there are strong, almost religious fanaticism-like opinions on coding standards, but they can't all be right. Therefore we need to be grown up and secular about it and accept that there are different ways of doing things, and it's OK to have different standards. But much as I wouldn't go into a synagogue and preach Buddhism, I would accept a given house coding style and get on with it, even if parts of it were not my own cup of tea. After all, a half decent programmer should be able to read any reasonably laid out bit of code, I am sure we all do that on a regular basis when we look up example code on the internet.
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: Suggestion on naming variables C
« Reply #30 on: March 30, 2015, 10:24:18 am »
Particularly in embedded systems, the fixed width datatypes are extremely useful.  A 'byte' might be an octet on the majority of platforms, but that doesn't help you when you are working on one of the exceptions.
Just out of curiosity: Are there still recent or widespread architectures with their respective development environments which use "byte" for a group of less than eight bits? Certainly, if one has to maintain ancient legacy systems one might have to face a scenario with a byte not being eight bits. But given that even the IEC 80000-13 standard recommends the term "byte" to be used for a group of eight bits (while acknowledging that "byte" has been used in the past to denote a number of bits other than eight), i wonder how relevant such consideration is in today's time...
 

Offline Stupid Beard

  • Regular Contributor
  • *
  • Posts: 221
  • Country: gb
Re: Suggestion on naming variables C
« Reply #31 on: March 30, 2015, 10:53:35 am »
Firstly, all you are citing is an opinion by someone else, it is not THE resource, it is A resource. How do you think we all managed before Joel came on the scene? We must've all been neanderthals. If you read what he has to say on it, he's essentially saying (rightly in my opinion) that Microsoft made a right old pig's ear of what was at the time fundamentally a good idea.

Secondly, HN isn't about indicating a variable's unsafe, it's about helping the programmer to help him/herself and make clear that the type is intended, not just slapped in there for no apparent reason, such as using an int64_t when an int8_t would do.

The point that I was trying to make was that there was/is a fundamental misunderstanding of the difference between physical type and logical data type. The difference is subtle, but important.

The group within Microsoft that originally used hungarian notation were referring to the logical data type. This is known as Apps Hungarian, and makes a degree of sense sufficient that it is hard to argue against it even if you hate hungarian notation.

A completely different group within Microsoft thought they were referring to the physical data type, and thus the abomination that is known as Systems Hungarian Notation was born. This gives you no information whatsoever beyond what the IDE can tell you, and is what most people refer to when they argue about it.

That, if memory serves correctly without double checking and running the risk of looking like an idiot, was the main point behind Joel's article and was the reason I linked it in the first place.

My point about safety was simply that it is an example of the logical data type that is of relevance in some situations, in particular when dealing with arbitrary user input. Thus, it actually is relevant to hungarian notation provided you are using apps hungarian.

Anyway, for what it's worth, I vehemently detest all forms of hungarian notation. I therefore find it slightly amusing that I am arguing in favour of apps hungarian.
 

Offline alexanderbrevig

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: no
  • Musician, programmer and EE hobbyist
    • alexanderbrevig.com
Re: Suggestion on naming variables C
« Reply #32 on: March 30, 2015, 11:14:22 am »
Firstly, all you are citing is an opinion by someone else, it is not THE resource, it is A resource.
In my opinion it is the resource on the subject. I forgot to point that out, but on subjects like this everything is inherently subjective opinions not objective facts.

The next bit is a head scratcher, I've re-read it a couple of times, you seem to be suggesting that HN is now a "best practice" in your opinion, but before you were against it?
No. Indicating content safety of the variable is a good idea and it's part of what the reasoning for HN is. I completely agree that it's not the entire motivation behind HN, but it is something that makes sense, and therefore something I've adopted (i.e rawSearchTerm instead of searchTerm when dealing with user input and databases for instance).

I should also add that as soon as I see the over-used expression "best practice" I hear alarm bells. It's a term often used far too frequently and lazily as a way of imposing something that is an opinion without having to justify it: it's saying to me if I don't do it your way then I am just wrong without you needing to supply any reason.
[...]
I do point out that it's a best practice in my view (that is, to indicate content safety by variable name). I've also spent one or two posts explaining the rationale behind my view, so maybe we should just agree to disagree?
As for your last blurb about code standards in terms of formatting etc, I've already pointed out my view on the matter.
Code smells are bad, weird formatting I can live with.
If a programmer is content with - and feel the need to embed type and scope in the variable name, then it's not someone I would want to work with.

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2294
  • Country: gb
Re: Suggestion on naming variables C
« Reply #33 on: March 31, 2015, 07:23:36 am »
Particularly in embedded systems, the fixed width datatypes are extremely useful.  A 'byte' might be an octet on the majority of platforms, but that doesn't help you when you are working on one of the exceptions.
Just out of curiosity: Are there still recent or widespread architectures with their respective development environments which use "byte" for a group of less than eight bits? Certainly, if one has to maintain ancient legacy systems one might have to face a scenario with a byte not being eight bits. But given that even the IEC 80000-13 standard recommends the term "byte" to be used for a group of eight bits (while acknowledging that "byte" has been used in the past to denote a number of bits other than eight), i wonder how relevant such consideration is in today's time...

A byte is the minimum addressable storage unit.  There are DSP's that aren't capable of addressing 8 bit value, yielding 16,24 or 32 bit bytes, e.g. the TI C55x, C62xx and C64xx DSPs all have 16 bit bytes and the Freescale DSP56k has 24 bit bytes.
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: Suggestion on naming variables C
« Reply #34 on: March 31, 2015, 05:50:28 pm »
A byte is the minimum addressable storage unit.
That simply is not true. Have you never heard about memory ICs which organize data in 1 bit or 4 bits, for example? Or DIMM modules which organize data accessible only in groups of 32 or 64 bits? Okay, perhaps you speak with regard to CPU/MCU/DSP architectures and instruction sets, in which case i would agree that this is very often the case, but not always.

Quote
There are DSP's that aren't capable of addressing 8 bit value, yielding 16,24 or 32 bit bytes, e.g. the TI C55x, C62xx and C64xx DSPs all have 16 bit bytes and the Freescale DSP56k has 24 bit bytes.
I guess you are perhaps confused. An architecture having as smallest addressable storage unit of a 16-bit word does not mean that suddenly the term "byte" becomes a synonym for "16-bit word". An architecture having as smallest addressable storage unit a 16-bit word just means that its smallest addressable storage unit is not a byte.

Neither TI nor Freescale seem to use the term "byte" in any other way than meaning 8 bit. Because, i have sampled the datasheets for Freescales DSP56311, TIs TMS320C6452 and TMS320C6455, and none of them utilize the term "byte" in a manner you suggest. Quite contrary, whenever they use "byte" it is clear that it means a group of 8 bits. But i admit, i did not check any single document there... Hence, could you please provide a link to any kind of documentation that showcases a usage of the term "byte" in the way you described?

(Well, i also checked FreeScale's "Beyond DSPs" document. Admittedly, at one point it speaks about omnious "32-bit bytes". Quote from page 8: "Unified, 32-bit byte addressable memory space". Too bad that this is only a typo, since obviously the intended statement was about 32-bit addressable memory space:P )
« Last Edit: March 31, 2015, 06:23:07 pm by elgonzo »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4816
  • Country: gb
Re: Suggestion on naming variables C
« Reply #35 on: March 31, 2015, 06:14:00 pm »
To be pedantic, a byte generally these days is 8 bits, but it wasn't always that way, and strictly speaking it doesn't have to be now. However anyone who talks about bytes not being 8 bits these days needs to be very, very clear within the context, and better still should avoid the use of "byte" at all, or else prepare to be slapped around the chops with a wet fish. (I was about to say "avoid the use of the word" but thought better of it).
« Last Edit: March 31, 2015, 06:19:04 pm by Howardlong »
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: Suggestion on naming variables C
« Reply #36 on: March 31, 2015, 06:17:49 pm »
(I was about to say "avoid the use of the word" but thought better of it).
:-DD  :-+  :clap:
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: Suggestion on naming variables C
« Reply #37 on: March 31, 2015, 06:49:44 pm »
(Well, i also checked FreeScale's "Beyond DSPs" document. Admittedly, at one point it speaks about omnious "32-bit bytes". Quote from page 8: "Unified, 32-bit byte addressable memory space". Too bad that this is only a typo, since obviously the intended statement was about 32-bit addressable memory space:P )

I don't read that as a typo. I read that as a 32-bit wide memory space, where each memory location can be accessed in 8-, 16- or 32-bit chunks. This is very common; it's why 16- and 32-bit memory devices have byte enables.
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: Suggestion on naming variables C
« Reply #38 on: March 31, 2015, 07:01:31 pm »
(Well, i also checked FreeScale's "Beyond DSPs" document. Admittedly, at one point it speaks about omnious "32-bit bytes". Quote from page 8: "Unified, 32-bit byte addressable memory space". Too bad that this is only a typo, since obviously the intended statement was about 32-bit addressable memory space:P )

I don't read that as a typo. I read that as a 32-bit wide memory space, where each memory location can be accessed in 8-, 16- or 32-bit chunks. This is very common; it's why 16- and 32-bit memory devices have byte enables.

Ahh, okay, no typo. That makes sense, now after reading your explanation - "byte addressable memory". Seems i was focused too much on finding/seeing "xx-bit bytes" phrases :)
(Just to be clear and in an attempt to avoid confusing other readers: That sentence still does not indicate or imply a case of a byte consisting of 32 bits...)
« Last Edit: March 31, 2015, 08:10:47 pm by elgonzo »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2294
  • Country: gb
Re: Suggestion on naming variables C
« Reply #39 on: April 02, 2015, 08:29:13 am »
I guess you are perhaps confused.

I guess perhaps not.  There is a good reason the word "Octet" came into being.
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: Suggestion on naming variables C
« Reply #40 on: April 02, 2015, 09:50:17 am »
I guess you are perhaps confused.

I guess perhaps not.  There is a good reason the word "Octet" came into being.

There is WAS a good reason the word "Octet" came into being.

In the ancient past, byte was also used to denote a group of 7 bits, for example (see ASCII). That's why there was a need to have a word other than "byte" that explicitly denoted a group of 8 bits. However, ancient past is long gone and "byte" and "octet" are synonyms nowadays (except for the few people who have to maintain ancient legacy systems, as i already mentioned). Somehow you seem to think that the presence of the term "octet" (as in telco/network protocol papers, for example) is somehow an indication that "byte" is still used to denote something else than a group of 8 bits. It isn't - those times are long gone (as manifested by the IEC 80000-13 standard, which also defines the "octet").

If you realize that many of those papers using "octet" had their foundations laid in the '60s or '70s of the last century it becomes obvious why they used and still the term "octet". For obvious reasons, even newer papers do use the same term, because it is (A) part of the established lingo in this field of expertise and (B) they might still refer to old papers, so it makes obvious sense to keep the same term for the same thing and avoid synonyms. Granted, if we were still in the 1970's or 1980's, i would wholeheartedly agree with the sentiment that "byte" might denote something different than 8 bits. However, that's about thirty...forty years ago...

Aside from that, how is the mere existence of the term "octet" in your opinion an indication for TI or FreeScale using the term "byte" in a different manner than denoting a group of 8 bit? You still seem to be confused, or i misunderstood your previous post fundamentally...  :D As it is, my question still stands: Are there still any recent or widespread architectures/systems out there in this day and age which use the term "byte" to denote groups of other than 8 bits (in documentation, in development tools, wherever...)?
« Last Edit: April 02, 2015, 10:43:06 am by elgonzo »
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9416
  • Country: my
  • reassessing directives...
Re: Suggestion on naming variables C
« Reply #41 on: April 02, 2015, 10:38:30 am »
computer scientists who first coined it, i dont know who... they are really terrible at making a standard, probably departed themselves from iso or metric standard idea... for them "byte" is contemporary unit, it was 7 bit now its 8 luckily it hasnt changed since then... similar to 1KB = 1024 bytes :palm: too obsessed with their digital or binary idea, its like they did decimal division in base 2? they smoked marijuana their brain should be boiled in liquid "sodder". lets make a byte is 8 bits now and forever shall we? 16bits = word, 32bits = long, 64bits = long long, 128bits = furlong. is that too difficult? :palm:
« Last Edit: April 02, 2015, 10:47:06 am by Mechatrommer »
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Suggestion on naming variables C
« Reply #42 on: April 02, 2015, 10:39:34 am »
In French it's octect, in Spanish is octeto, but in Spain people colloquially use bytes, not so much in France.
But they do know that a byte is :)

Not dissing the French, just the French Academy of Language :)
 

Offline mushroom

  • Regular Contributor
  • *
  • Posts: 70
  • Country: fr
Re: Suggestion on naming variables C
« Reply #43 on: April 02, 2015, 11:04:59 am »
In french, there is another reason not to use byte. Byte is read and pronounced the same as bite ("beet"). And bite means cock.

It is octet, not octect.

French Academy is a comitee of old beards fighting against everything is not french, and even not parisian. They invented "mél" to replace "mail" : it is pronounced exactly the same, and "mél" has absolutely nothing to do with any latin langage. But they have been paid to invent this word. And even French Academy of Science has to follow their dictat ! There are laws and fees, even for scientific publications.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Suggestion on naming variables C
« Reply #44 on: April 02, 2015, 11:12:15 am »
sorry, was a typo
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: Suggestion on naming variables C
« Reply #45 on: April 02, 2015, 11:35:20 am »
In french, there is another reason not to use byte. Byte is read and pronounced the same as bite ("beet"). And bite means cock.
Sounds like a cross between 'PC Master Race' and Japanese tentacle Hentai. "I really love my new rig. It has 32 Giga cocks."   :wtf:  Excuse my French... ;)
(I'm sorry... went totally off-topic... :-[ but i couldn't resist...)
« Last Edit: April 02, 2015, 11:43:32 am by elgonzo »
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Suggestion on naming variables C
« Reply #46 on: April 02, 2015, 11:59:38 am »
So byte is to beet like chat is to chatte?

But there are no cats in programming! Maybe in music playing the strings.

And to chat is to speak it doesn't mean pussy cat. Or is that chatte chat?

Languages are funny and I'm confusing myself :)
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9416
  • Country: my
  • reassessing directives...
Re: Suggestion on naming variables C
« Reply #47 on: April 02, 2015, 04:54:48 pm »
...it doesn't mean pussy cat...
i learnt different meaning of "pussy" :palm: but lets not talk about it...
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3400
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Suggestion on naming variables C
« Reply #48 on: April 02, 2015, 07:35:47 pm »
You're free to typedef you own variable names based on what you like. It will be interesting showing the software to anyone else if the variable types are various female body parts.
Maybe something to add to this quickly googled list http://tutorialzine.com/2013/12/the-10-weirdest-programming-languages/, PusC?

Anyways... uint8_t prevents any ambiguity, so I'd recommend using stdint.h types in professional environments.
 

Offline alexanderbrevig

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: no
  • Musician, programmer and EE hobbyist
    • alexanderbrevig.com
Re: Suggestion on naming variables C
« Reply #49 on: April 02, 2015, 07:51:38 pm »
It's also at the utmost importance to remember to
Code: [Select]
#define true false :box:


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf