Organize the C++ name Convention

[HarD Gamer]

If you try to look at the C++ name convention, you will see who it doesn't exists, and will wanna see some over that. If you look at frameworks (Qt, for example), you will see that have a uniform and elegant name convention. This document proposes an unique name convention for the C++ Programming Language, which actualy have a mix of various. This will make, for example, ifstream, high_resolution_clock, Allocator and unordered_multimap be InputFileStream, HighResolutionClock, Allocator and UnorderedMultimap [or UnorderedMultiMap]. And adjust where some functions are placed (eg., make to_string() a public static metod of the BasicString [old basic_string] class. 

complete proposal: https://drive.google.com/file/d/0ByuvcS4SVVx8SldaRHc4N3l2WEU/view?usp=sharing

[Ren Industries]

This would be the most breakingest change ever created; how would backwards compatibility be achieved?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6e859837-fdb0-44d9-9672-f0f1f2a531ad%40isocpp.org.

[D. B.]

No

[Thiago Macieira]

On terça-feira, 9 de agosto de 2016 10:08:20 PDT HarD Gamer wrote:
> If you try to look at the C++ name convention, you will see who it doesn't
> exists, and will wanna see some over that. If you look at frameworks (Qt,
> for example), you will see that have a uniform and elegant name convention.
> This document proposes an unique name convention for the C++ Programming
> Language, which actualy have a mix of various. This will make, for example,
> ifstream, high_resolution_clock, Allocator and unordered_multimap be
> InputFileStream, HighResolutionClock, Allocator and UnorderedMultimap [or
> UnorderedMultiMap]. And adjust where some functions are placed (eg., make
> to_string() a public static metod of the BasicString [old basic_string]
> class.

That will never pass.

Instead, I suggest you write a set of guidelines for future uses that reflect
the current uses. You're free to point out bad names not to be repeated, but
the resulting new code should still feel like the Standard Library.

PS: I dislike the Standard Library naming convention.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Peter Koch Larsen]

HiHarDCoderOneThingIGuessWeCanAllAgreeOnIsThat_camel_case_is_far_more_readable_than_separation_by_underscores.

/Peter

[Reza Jahanbakhshi]

HiHarDCoderOneThingIGuessWeCanAllAgreeOnIsThat_camel_case_is_far_more_readable_than_separation_by_underscores

Interestingly, in your example the second part is far more readable to me which is separation by underscores. I had a hard time to read the first part which is camel case but at first glance I could read the second part.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknyFORjYkrzL5KYQjjf_TC7_sb8L3a3y7Dq2ei8nytAK9Q%40mail.gmail.com.

[Viacheslav Usov]

On Wed, Aug 10, 2016 at 7:20 AM, Reza Jahanbakhshi <reza.jah...@gmail.com> wrote:

HiHarDCoderOneThingIGuessWeCanAllAgreeOnIsThat_camel_case_is_far_more_readable_than_separation_by_underscores

Interestingly, in your example the second part is far more readable to me which is separation by underscores. I had a hard time to read the first part which is camel case but at first glance I could read the second part.

I think that was the whole point of that message.

Cheers,

V.

[Bo Persson]

On 2016-08-10 07:20, Reza Jahanbakhshi wrote:
> HiHarDCoderOneThingIGuessWeCanAllAgreeOnIsThat_camel_case_is_far_more_readable_than_separation_by_underscores
>
>
> Interestingly, in your example the second part is far more readable to
> me which is separation by underscores. I had a hard time to read the
> first part which is camel case but at first glance I could read the
> second part.

There might be a cultural difference here.

If you speak German, or Dutch, or a Scandinavian language, you combine
words like this all the time IRL. And without even capitalizing the parts.

http://theweek.com/articles/463500/8-favorite-ridiculously-long-german-words


Having underscores in words seems very strange though. :-)


Bo Persson

>
> On Wed, Aug 10, 2016 at 8:13 AM, Peter Koch Larsen
> <peter.ko...@gmail.com <mailto:peter.ko...@gmail.com>> wrote:
>
> HiHarDCoderOneThingIGuessWeCanAllAgreeOnIsThat_camel_case_is_far_more_readable_than_separation_by_underscores.
>
> /Peter
>
> On Tue, Aug 9, 2016 at 7:08 PM, HarD Gamer <rodrigo...@gmail.com
> <mailto:rodrigo...@gmail.com>> wrote:
>
> If you try to look at the C++ name convention, you will see who
> it doesn't exists, and will wanna see some over that. If you
> look at frameworks (Qt, for example), you will see that have a
> uniform and elegant name convention. This document proposes an
> unique name convention for the C++ Programming Language, which
> actualy have a mix of various. This will make, for example,
> ifstream, high_resolution_clock, Allocator and
> unordered_multimap be InputFileStream, HighResolutionClock,
> Allocator and UnorderedMultimap [or UnorderedMultiMap]. And
> adjust where some functions are placed (eg., make to_string() a
> public static metod of the BasicString [old basic_string] class.
>

> <https://lh3.googleusercontent.com/-zVyFz8nSGjU/V6oNsvbDxAI/AAAAAAAAAPE/FpDHBxvaawsIXgUngrYmphUMDWeTMLVPgCLcB/s1600/proposal.png>
>
> complete
> proposal: https://drive.google.com/file/d/0ByuvcS4SVVx8SldaRHc4N3l2WEU/view?usp=sharing
> <https://drive.google.com/file/d/0ByuvcS4SVVx8SldaRHc4N3l2WEU/view?usp=sharing>
>

[D. B.]

At this stage, it doesn't really matter what most people agree is most readable, even if we can make most of them agree on anything. The point is that all the names already exist, and C++ values backwards compatibility over most other things. Someone saying 'I find this hard to learn and remember' is totally irrelevant in that context. Those names are what they are, and they must continue to be so. Just learn them and be done with it. I did. And I prefer a very different naming convention for my own stuff. Yet somehow I manage to hold these two contradictory ideas in my mine and get on with programming.

[Peter Koch Larsen]

On Wed, Aug 10, 2016 at 12:16 PM, Bo Persson <b...@gmb.dk> wrote:
> On 2016-08-10 07:20, Reza Jahanbakhshi wrote:
>>
>>
>> HiHarDCoderOneThingIGuessWeCanAllAgreeOnIsThat_camel_case_is_far_more_readable_than_separation_by_underscores
>>
>>
>> Interestingly, in your example the second part is far more readable to
>> me which is separation by underscores. I had a hard time to read the
>> first part which is camel case but at first glance I could read the
>> second part.
>
>
> There might be a cultural difference here.
>
> If you speak German, or Dutch, or a Scandinavian language, you combine words
> like this all the time IRL. And without even capitalizing the parts.

I am Scandinavian, and it is correct that we tend to combine words.
But not using underscores. ;-)
I also believe that using underscores make words more readable.

>
> http://theweek.com/articles/463500/8-favorite-ridiculously-long-german-words
>
>
> Having underscores in words seems very strange though. :-)
>

I believe that replacing spaces with underscores is the best solution
until we decide to allow spaces in identifiers. ;-)

[D. B.]

On Wed, Aug 10, 2016 at 3:07 PM, Peter Koch Larsen <peter.ko...@gmail.com> wrote:

I believe that replacing spaces with underscores is the best solution
until we decide to allow spaces in identifiers. ;-)

Don't worry, the big boss has got operator ' ' on the way, so you won't even need to use spaces in identifiers. Rather, every identifier will be exactly 1 character in length, and you'll combine multiple identifiers and operator ' ' into complex chained calls and overloads, in order to achieve any desired result. Infinite variety in infinite combinations. The very concept moves me deeply. See the working paper: http://www.stroustrup.com/whitespace98.pdf

[Jim Porter]

On 8/10/2016 5:22 AM, D. B. wrote:
> The point is that all the names already exist, and C++ values
> backwards compatibility over most other things. Someone saying 'I
> find this hard to learn and remember' is totally irrelevant in that
> context. Those names are what they are, and they must continue to be
> so.

That's not necessarily true. As I recall, there's been talk of a second
version of the C++ standard library to allow for breaking changes (e.g.
range-based collections). However, I doubt anyone will support a massive
change in conventions like this suggestion, especially when
underscore_names are already quite readable.

- Jim