Suggestion on naming variables C

[Vindhyachal.takniki]

Now I am trying to name variables by below method. Any suggestions/comments

1. All vars should of be atleast 3 chars like cnt,loop. Declaring i is incorrect.
2. Datatype of var should be visible from its name Like u32_cnt.


1.Global var: g_u32_loop
2. global constant: gc_u8_loop
3. Static var: s_i16_loop;
4. static constant: sc_c8_loop;
5. local var: f32_loop;
6. local const: c_f64_loop;
7. ptr: p_u16_cnt

[cellularmitosis]

You'll find these style choices are largely dependent upon how powerful your editor.

In Xcode, for example, I no longer shy away from verbose names.  When you have intelligent autocomplete and refactoring tools, class names like MyShipmentsViewController become commonplace (rather than something like ShipmntsVC).

But you are already on the most important part of the path: become opinionated and desire to follow conventions of your own design, because you care about the little things!  Over the next five years you will change your personal conventions a dozen times, and that's ok.

[krish2487]

as cellularmitosis has suggested - these issues are largely individual in nature.
However,
read about hungarian naming convention and MISRA C rules.
In the end, develop a system that works for you and that you can maintain and implement consistently. Developing a system is easy, consistently using it is hard. So develop a system that is easy to follow.

[miguelvp]

as krish2487 suggests read up on hungarian notation
http://en.wikipedia.org/wiki/Hungarian_notation

at least that way if someone needs to collaborate in the source, they will be familiar with that notation.

[sleemanj]

2. Datatype of var should be visible from its name Like u32_cnt.

I hate that personally, not only because it's pointless nomenclature which can readily be seen by looking at the variable definition (and if you can't remember the variable definition, how are you going to remember the variable name anyway!), but because if you ever want to change the type (or potentially even machine architecture) now instead of changing a handful of definitions, you have to go through and change all the variable names, AND remember these new variable names, many of which are virtually in muscle memory if you are writing the code for any length of time.

Similarly, mandating that variables be "3 characters" is silly, there are countless times when you require simple indexes in a for loop - x, i, j and k are well-trodden and perfectly good index variable names, as long as their scope is small.

As far as I'm concerned such floweriness is just superfluous cruft designed to waste keystrokes and slow the thought process when mentally referring to variables.

It's bad enough using stupid datatype names like "uint_8" instead of the perfectly simple "byte".


 

[miguelvp]

I personally don´t like them (hungarian notation or the like) but sometimes I must use them if the piece of code at hand follows that standard.
I kind of tend to try not to leave mismatch notation/format trails.

Plus nowadays IDEs will let you know what it is just by hovering over it.

[Stupid Beard]

Read http://www.joelonsoftware.com/articles/Wrong.html
Read it all.
Kill the abomination now before it is too late.

[Jeroen3]

"uint8_t" types are defined in stdint.h, "byte" isn't.
Using byte will give you an extra useless define creating a type that is unnecessary.

Instead of prefixing the type. Prefix the module if you extern them.
Prefixing the type might help if you have a lot of casts and your code needs to be validated.

[Michaela Joy]

@Stupid_Beard: That article is -great-  Thanks for posting it.

If you're coding a project yourself, then use whatever naming convention makes the most sense to you. If someone else may need to or will be working on your code, then make it as readable and understandable as possible. Use comments on things that are not clear, but do not over-comment.

:MJ

[elgonzo]

It's bad enough using stupid datatype names like "uint_8" instead of the perfectly simple "byte".

While i agree with the rest of your argument, i disagree with this particular sentence.
"uint_8" makes it explicitly clear what range of values can be represented by this datatype: [0,255].
"byte" is less clear about this - is it a signed or unsigned data type? Unfortunately the datatype "byte" is already used differently by different programming languages/frameworks - for example, in Java byte is signed ([-128,127]), in C# it is unsigned ([0,255]). Speaking about "perfectly simple", ehh...


@Stupid_Beard, +1 for linking this execellent article

[IanB]

Now I am trying to name variables by below method. Any suggestions/comments

1. All vars should of be atleast 3 chars like cnt,loop. Declaring i is incorrect.
2. Datatype of var should be visible from its name Like u32_cnt.


1.Global var: g_u32_loop
2. global constant: gc_u8_loop
3. Static var: s_i16_loop;
4. static constant: sc_c8_loop;
5. local var: f32_loop;
6. local const: c_f64_loop;
7. ptr: p_u16_cnt

There's nothing wrong with using single letters like i, j, k as loop variables (as long as it is a small loop and the scope of the variable is clear). Mind you, making big long loops that don't fit on the screen is bad design, so don't do that.

Try to make all variable names read like proper language (human language or mathematical language). Use words that describe the contents of the variable, like "itemPrice" or "itemQuantity". Do not waste letters on things like "u16" or "f32" since the variable declaration holds that information and a good code editor can quickly tell you what it is.

In mathematical language it is common to index an array as, for instance, a_ij , so it's quite natural to write a[i,j] in code to mean the same thing.

[economist]

There's nothing wrong with using single letters like i, j, k as loop variables (as long as it is a small loop and the scope of the variable is clear). Mind you, making big long loops that don't fit on the screen is bad design, so don't do that.

Try to make all variable names read like proper language (human language or mathematical language). Use words that describe the contents of the variable, like "itemPrice" or "itemQuantity". Do not waste letters on things like "u16" or "f32" since the variable declaration holds that information and a good code editor can quickly tell you what it is.

In mathematical language it is common to index an array as, for instance, a_ij , so it's quite natural to write a[i,j] in code to mean the same thing.

Completely agree with this. In 30 years of coding in various languages I always come back to readability of code as being the key thing. Follow that with consistency and plenty of comments and just about any sensible system can work.

[bitshift]

Now I am trying to name variables by below method. Any suggestions/comments

1. All vars should of be atleast 3 chars like cnt,loop. Declaring i is incorrect.
2. Datatype of var should be visible from its name Like u32_cnt.


1.Global var: g_u32_loop
2. global constant: gc_u8_loop
3. Static var: s_i16_loop;
4. static constant: sc_c8_loop;
5. local var: f32_loop;
6. local const: c_f64_loop;
7. ptr: p_u16_cnt

There's nothing wrong with using single letters like i, j, k as loop variables (as long as it is a small loop and the scope of the variable is clear). Mind you, making big long loops that don't fit on the screen is bad design, so don't do that.

Try to make all variable names read like proper language (human language or mathematical language). Use words that describe the contents of the variable, like "itemPrice" or "itemQuantity". Do not waste letters on things like "u16" or "f32" since the variable declaration holds that information and a good code editor can quickly tell you what it is.

In mathematical language it is common to index an array as, for instance, a_ij , so it's quite natural to write a[i,j] in code to mean the same thing.

+1

Just to add, I don't think you should separate identifiers with the "_" character. While this could be considered "nice to read", its a bitch to type because you have to hold shift.

Some of the major "rules" I tend to follow:

• Always think about how the next guy reading your code will interpret it. He won't necessarily have the same context you have so keep it simple and readable.
• "Never" use abbreviations. Rather use full names like itemQuantity over itemQty. This example is obvious, but it won't always be.
• Avoid generic names like "loop". Your variable names should describe their semantic function.
• Favor readability and maintainability over performance. Only worry about performance once you've identified a problem.
• In whatever you choose be consistent.

This rather short list could go on forever...

In summary, keep it simple, short and readable!

[Howardlong]

Having your own standard is a personal thing, and being religious about it saying something like camel case is stupid, or Hungarian notation is for losers is like me saying you're stupid if you like peanut butter and jelly sandwiches. It's a personal taste, I don't get peanut butter and jelly sandwiches, but I'm not going to deprive or denigrate someone if they like them.

In support of Hungarian notation, the point is, particularly in C, to make an effort to save programmers from themselves when they do silly things like signed/unsigned comparisons or other implicit type conversions. These days, as long as the warning level is sufficiently high, the compiler will complain, and yes, we do have editors these days that will tell you the type. However despite this I have see enough missed (or worse, deliberately hacked) silly type conversion functional bugs in my life, from programmers who I thought would know better, to realise that having some indication of type in the variable name is not superfluous to my mind. Finally, I've been doing HN since the late 80s and I'm a bit long in the tooth to start changing now, I'm comfortable in my own skin if you like.

However, I am open minded enough to accept that other folks see Hungarian notation as unnecessary, and I don't get all precious about it if that's what floats (did you see what I did there?) their boat.

What is more important than coding standards (whatever they may be) is maintaining consistency.

[mikerj]

It's bad enough using stupid datatype names like "uint_8" instead of the perfectly simple "byte".

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.  What name would you give to e.g. 16 bit and 32bit data types that clearly relates to the data types size and would remains consistent on all platforms?

[Howardlong]

It's bad enough using stupid datatype names like "uint_8" instead of the perfectly simple "byte".

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.  What name would you give to e.g. 16 bit and 32bit data types that clearly relates to the data types size and would remains consistent on all platforms?

 

Before stdint.h became generally established, I had implementation specific typedefs in a header file, eg S8, S16, S32 and U8, U16 etc. It allowed me to easily test algorithms natively on the PC that eventually might target 8 or 16 bit embedded systems. Using BYTE is not so bad, but far worse is WORD as in Windows which was was a silly mistake for the Windows guys, especially when they started messing with WPARAM. Pretty much every port from Win16 to Win32 was became time consuming chore as a result.

[xrunner]

In college I had a schoolmate that wrote a program and all his variable names were ... ahem ... basically profanity. Then, when he couldn't get it to work per the assignment, he had to take it to the professor at the last minute and didn't have time to change all the variable names. I wish I had been a fly on the wall in that room. 

[AlfBaz]

In college I had a schoolmate that wrote a program and all his variable names were ... ahem ... basically profanity.

Although I use it all the time, I often find cnt troubling

[alexanderbrevig]

When I review code, there are a few rules that - when broken - will prompt me to give up on the project or the programmer:

• No hungarian notation (g_pasz_dictionary  )
• No flooding of global variables, there should be as few as possible
• Undescriptive or overly technical variable names
• Too much or too little commenting (the code should document itself as much as possible)

Things like casing, spacing, tabs, order of declaration etc are things of less importance.
If I must contribute to a team with extremely weird formatting, then I convince them to specify their rules as an AStyle format, then I have hooks with git that translates to- and from their format upon commits.

tl;dr

Please do not ever use hungarian notation. Not. Ever. 

And this joke:

Code: [Select]

/* it was hard to write, and should be hard to read */Is only funny when you do not read it as the only comment in a file.

[Howardlong]

When I review code, there are a few rules that - when broken - will prompt me to give up on the project or the programmer:
...
Please do not ever use hungarian notation. Not. Ever. 

Crikey, sounds like you're running a fun ship there, must be a barrel of laughs!

While it is valid to adopt the house coding style to create consistency, and that outweighs the choice of coding standards themselves, there are other opinions out there ya know. I didn't actually see your justification in opposing HN, I might've missed it though.

[Mechatrommer]

Now I am trying to name variables by below method. Any suggestions/comments
1.Global var: g_u32_loop
2. global constant: gc_u8_loop
3. Static var: s_i16_loop;
4. static constant: sc_c8_loop;
5. local var: f32_loop;
6. local const: c_f64_loop;
7. ptr: p_u16_cnt

good luck typing all that in your code. my rule is... readable while easy to type... above all dont give personal taste too much emotionally attached, it can waste alot of good time that can be spent coding real stuffs. there is one tool that can fix every problem in this universe... edit->replace. i was in your path....

[Stupid Beard]

When I review code, there are a few rules that - when broken - will prompt me to give up on the project or the programmer:
...
Please do not ever use hungarian notation. Not. Ever. 

Crikey, sounds like you're running a fun ship there, must be a barrel of laughs!

While it is valid to adopt the house coding style to create consistency, and that outweighs the choice of coding standards themselves, there are other opinions out there ya know. I didn't actually see your justification in opposing HN, I might've missed it though.

It depends which version of hungarian. I don't know what the original poster was getting at, but this is what goes through my head when I see hungarian notation:

If it is used to indicate the type of the variable then that is an indication that that programmer doesn't understand the actual intent behind hungarian notation and has almost certainly just made things more annoying to read and write for no clear benefit.

If it is used to indicate the actual datatype (e.g. null terminated string vs string terminated in some other way) then as long as they haven't also used it in the misinterpretation way, that's generally sensible. I wouldn't say required, but I can understand why you'd do it.

If it is used to indicate something important, for example to separate unsafe data from safe or sanitized data, then that is a very sane thing to do that everybody should do to some degree, depending on what their code is for. It is hard to form an argument against that because using the wrong thing in the wrong place can have catastrophic consequences far beyond your code.

In my opinion it is important to understand the genuine reasoning behind things and separate out what is just personal preference. In the case of hungarian notation, if you do that and still prefer to use the misinterpretation of it then that's totally fine.

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.

[hamster_nz]

Please do not ever use hungarian notation. Not. Ever. 

When I first came across Hungarian notation, it was in the days of Windows 3.0.

I feel it came about as in those days programmers got quickly confused by they way programming environment and resources greatly exceeded what could easily be addressed (remember the days of near, huge and far pointers?), and PC coders were just getting used to the idea that they didn't own everything.

The API was also a bit cluggy, with some interfaces requiring handles, others requiring pointers, some needing handles to pointers, then there were WORDs, DWORDs and QWORDs and so on. Also i10n/i18n was also big, so Unicode support became an issue, and new territory for most coders.

To make matters worse you sometimes had to cast from one type to another - e.g. you might have a handle to a device context, but cast it to a generic handle for an API call (e.g. to release the handle).

The standard response of the time was to be explicit about what everything was, so it sort of became instantly apparent if you had typing issues - hDC, hBrush, nCount, pszText, cConstant, cszNullTerminatedStringConstant, pcszPointerToNullTerminatedString blah, blar, blar.

Now that the problems which caused the issues have largely gone away. We have OOP languages, extensive class libraries encapsulating and hide the rougher edges of APIs, better languages and/or better compilers with better type better checking, oodles of RAM, CPUs with registers that can hold pointers pointers that can address the full memory space and so on.  And we also have awesome IDEs that will tell you want a variable is just by hovering a pointer over it.

Because of this Hungarian notation is largely a relic. However, also have a lot of programmers who found great utility in using it to address what are largely yesterday's problems, so some people have become very attached to it.

Strangely enough, UNIX is largely free of this, as everything was pretty much a 32 bit integer or a 32 bit pointers and the OS API was relatively clean - for example, sockets, pipes and file handles are just integers and you can read or write from either, not hFile, hPipe or hSocket .

[691175002]

I used to use Hungarian notation in the past but over time I realized it was just a huge waste of time, and is very uncommon among other programmers.

Ninety nine percent of the time the type of a variable should be obvious from its context.  In the rare cases where it isn't, use a comment to clarify.

I've noticed that you generally only see underscores in code that is a least a decade old as well.  Nobody needs to type the _ character when camel case is just as good.  Only place I would use them are in all-caps constants.

[c4757p]

You dislike underscores of all things? I find snake_case to be significantly more legible than CamelCase.

[hamster_nz]

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.

[Mechatrommer]

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.

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.

[mikerj]

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.

[alexanderbrevig]

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.

[Howardlong]

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.

[elgonzo]

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...

[Stupid Beard]

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.

[alexanderbrevig]

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.

[mikerj]

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.

[elgonzo]

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.

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.  )

[Howardlong]

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).

[elgonzo]

(I was about to say "avoid the use of the word" but thought better of it).

   

[Bassman59]

(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.  )

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.

[elgonzo]

(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.  )

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...)

[mikerj]

I guess you are perhaps confused.

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

[elgonzo]

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...  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...)?

[Mechatrommer]

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 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?

[miguelvp]

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

[mushroom]

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.

[miguelvp]

sorry, was a typo

[elgonzo]

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."     Excuse my French...
(I'm sorry... went totally off-topic... but i couldn't resist...)

[miguelvp]

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

[Mechatrommer]

...it doesn't mean pussy cat...

i learnt different meaning of "pussy" but lets not talk about it...

[Jeroen3]

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.

[alexanderbrevig]

It's also at the utmost importance to remember to

Code: [Select]

#define true false