Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A case against UPPERCASE constants #96

Open
sasq64 opened this issue Nov 23, 2018 · 3 comments
Open

A case against UPPERCASE constants #96

sasq64 opened this issue Nov 23, 2018 · 3 comments

Comments

@sasq64
Copy link

sasq64 commented Nov 23, 2018

My argument is that avoiding all-uppercase for all non-macros avoids those hard to understand errors you get when you use a constant or enum value that was already defined in some external header.

Ever had to do #undef ERROR after including Windows.h ?

@Cazadorro
Copy link

Cazadorro commented Nov 27, 2018

Sure, there's a case against upper case constants, but how else are you going to specify global scope immutables immediately? You need to come up with a solution, because it is very annoying trying to figure out where a variable I'm looking at comes from only to find out it was defined in a header file I'm including, and isn't a part of the class I'm looking at.

Enums can be upper camel case because you think of the values almost as types in their own right, but using enum classes disambiguates where they come from anyway, so signifying with caps isn't needed. Global constants, on the other hand, need to be something that's signified exists outside of the current scope and isn't going to be modified underneath you. Capitalization was the easiest way to signify this, but I agree, this does conflict with macros. There needs to be something to replace it if you are going to make that argument.

@Cazadorro
Copy link

Cazadorro commented Nov 27, 2018

Actually I have an idea for a replacement. Given the Always Use Namespaces rule, how about we change the rule for global constants to always scope with at least first namespace? ie:

namespace xyz{
    const int const_example = 3;
    ...
    class Abc{
    private:
        int m_baz;
    public:
        int foo(){
            int bar = m_baz * xyz::const_example;
            return bar;
        }
    }
}

This wouldn't apply to local constants, as you know exactly where they are defined. This could apply to class static constants used internally in a class, but regardless they are already forced to use the class namespace when used outside of a class. Non static class constants are essentially local constants, so again they wouldn't need to be scoped.

Now you know the global constant comes from a different scope, and you can understand that it is a constant by usage, rather than second guessing where it came from. Outside the namespace you already have to scope, so it doesn't create more code for the user of your API, just internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants