More FAQ updates

[TheIdeasMan]

shadowmouse wrote:

... maybe standard names that make things easier to read (i for index, j for next nested index, T for first template type e.t.c.).

Just my pedantic objection to i and j for index variables, I prefer a small word for these - such row and col if that is what they are. My reason for this is as follows:

I was helping someone who was doing code for a large matrix over which a small matrix was being used to do processing. There were 2 pages of code full of i and j. To help with the problem, I suggested replacing i and j with Row and Col. The problem became immediately apparent - there was a (Row, Row) which should have been (Row, Col)

Of course, one might use different chars that don't look so similar.

I guess the exception to single char variables names, is when they come from a mathematical formula. Even then, there might be some that argue that r, x, y could be changed to Radius, XOrdinate, YOrdinate

Btw, I am not objecting to T etc for template types.

Anyway - really good work to Duoas for all the effort put in the FAQ :+D

[shadowmouse]

I mainly use i and j when when they refer to different things such as a setup like this:

for(auto&i :ExampleContainerOne)
{
    for(auto&j :ExampleContainerTwo)
    {
        if(i == j) {doSomething}
    }
}

I would also suggest that if you use a good font and aren't too zoomed out, these mistakes will be immediately obvious. Besides, i and j save quite a lot of time and horizontal space and what would you put instead of row and col if there's more than one nested loop? I find sticking with convention and employing a quick proofread tends to work fine.

[TheIdeasMan]

@shadowmouse

Just quickly, as to not to derail the thread:

Could you use two chars that look different? I guess the example I posted, violated the rule of short scope for such names.



I read the articles Duoas linked. The first I thought was very sensible. The 3rd by Charles Simonyi, was diametrically opposite - the code at the end was atrocious IMO - I guess that is why HN became unpopular.

[MiiNiPaa]

the code at the end was atrocious IMO

It is actually pretty standard C code for the mid-90.
Aside fom code which looks atrocious today, Simonyi did not do a good job explaining and demonstrating his intent. So this article is more like curiosity today. Making Wrong Code Look Wrong describes it better today.

[Duthomhas]

Well, I'm playing with an image map.
http://www.cplusplus.com/faq/beginners/variable-names/#common
Please try it on your various browsers and tell me which ones look awful. (Not all the links are there yet.)

If it doesn't work, I'll do a much more boring layout in a table.

@TheIdeasMan
+1
I'll update the image to include row and col for matrix/table type things.

I still have to add a few more examples up there. If anyone can come up with a good one for nested loops that isn't a bubble sort, please post it.

Re: Simonyi
I misunderstood his article the first time I read it too.

[MiiNiPaa]

Firefox 39.0 Win 7 text is slightly blurry and image map does not work. http://puu.sh/iL0ku/f2dc5f757b.png

If anyone can come up with a good one for nested loops that isn't a bubble sort, please post it.

Shaker sort? :)

Printing a map <number, vector of prime factors>?

[Duthomhas]

Sorry, I forgot that the map name must be referenced with a hash: <img usemap="#foo" ...

I also had a bad width value in there, which would cause the image to be blurry.

Let me know if I managed to fix it.

Shaker sort? :)

LOL.

I could put a Floyd-Warshall function as example. Do you think it would matter if the very idea of the function went over most readers' heads?

[MiiNiPaa]

Now everything is working properly.

[andywestken]

More on names:

I see you have ss, iss, and oss (for stringstream, istringstream and ostringstream) but not fs, ifs and ofs (for fstream, ifstream and ofstream), which happen to be the ones I favour. I also use is and os for istream and ostream.

But I don't like using s for a stream, as s says string to me (like str.) So I usually use strm.

And row, col could be added to the ccordinates table (I like them for 2d arrays.)

And psz and sz are common for char*s.

Andy

[Duthomhas]

ACK.

(The file/streams one is already really big... I'm going to have to think about it a little more to fit all the information in.)

's' by itself isn't listed for a stream; just a string.

I was trying to keep coordinates and matrix/arrays separate.

I'll and the sz stuff to char*s.

I'll post again when I get it done.

@MiiNiPaa
Yay!

[giblit]

Why is the file and stream section listed 3 times on the naming page? Also you could list namin conventions such as CamelCase sorry using phone and didn't realize the link went to bottom of the page

[Duthomhas]

Why is the file and stream section listed 3 times...

Because I'm making screenshots to compile into the image that will ultimately appear. ;-)
(There's no offline editing ability on the FAQ. You see the changes as I make them.)

At this point, I believe I got the image done. All that's left is some final examples.

[Duthomhas]

Alright, I think that's all I'm going to do for the "names of things" page. It's feeling a little example-heavy...

(Maybe I should have a FAQ page just to hold examples to link to).

There's still no example for "coordinates" or "distances", but enough's enough, I figure.

Final thoughts?
http://www.cplusplus.com/faq/beginners/variable-names/

[megatron 0]

Very informative.

Question: Does the 30 char limit still apply? Why 30?

[Duthomhas]

31. IIRC, compiler writers can exceed that limit if they want. The point was that 30 characters is a lot.

(If you can come up with a long identifier like that that is exactly 31 characters long, let me know.)

IDK why 31 was chosen. An sz string would be a maximum of 32 characters long. Maybe it was just a fixed field in some struct in early C compilers, aligned to DWORD boundries? Guesses, guesses.

[megatron 0]

(If you can come up with a long identifier like that that is exactly 31 characters long, let me know.)

I can barely get past 10. This is why this information astounded me I've never came across this. :^]

Ah, 32 sounds right. Just 30 seemed.. odd to me, but I think I'm spending too much time at the computer these days.

[TheIdeasMan]

Duoas wrote:

Re: Simonyi
I misunderstood his article the first time I read it too.

Just quickly: I read Joel Spolsky's article quite awhile ago. Sure combating unsafe strings is a good idea, but the tags used by Simonyi are insufferably bad IMO. At least they don't seem to conform to a [my?] reasonable concept of how things should be abbreviated. e.g sz to me means size, us means unsigned. Presumably pointer to us is pus _{couldn't resist a little joke}

With the tags, I would still prefer a longer variable name over something that might cause confusion. Even if it is UnSafeUserName, or something even longer.

These days I am sure nearly everyone is over HN, but hopefully someone new reading Simonyi's article won't think that the code at the end is a good idea. In the horrible names section, maybe there could some short comment about the wise intention of Simonyi's system, but for the love of sanity - don't write code like that. I mean, it's a bit like using the vi editor to write brainf@!k code :+) _{another joke} We should protect ourselves from beginners posting their own variations using Simonyi's naming system.

Hope all is well at your end, and you are enjoying a stress free weekend - cheers :+)

[MiiNiPaa]

us means unsigned

For me unsigned is u. As unsigned makes no sense for string, we will not mix unsafe string with unsigned. Also, there is no sense to have unsigned tag at all (as lons it is not signed integer which value should not be negative by program logic).

[Duthomhas]

All abbreviations exist for convention -- you have to know what it means.

If I'm working on a graphics program, and I use the variable 'x', you know automatically that it is a horizontal coordinate.

'us_name' works the same way -- you know that the 'name' string is unsafe -- or you've never seen it before and shouldn't be touching the code.

I think it was JSmith who made an argument for strict typing to make the compiler do this kind of stuff... I'm still considering adding something about that to the FAQ -- at least a link to the discussion we had on the forum.

I'll add a line that discourages use of HN. (Thanks for catching it's absence.)

[TheIdeasMan]

@MiiNiPaa



My earlier reply was to say that I knew what the purpose of Simonyi's article was. But I shouldn't have objected to it: I am sure millions have over the decades, and hopefully we are all over it now. However I wouldn't like to see beginners posting code like that on our forums.