RE: "Constants should be declared in all caps."

Continuing the discussion from What am i doing wrong?:

I think that applies to #define in C, not as much in JS.

It is a general convention and sometimes a rule


There are many different cases you can use, ultimately everything comes down to preference. Generally I use camelCase as a default and it seems to be a generic standard for most languages, but for some reason Python programmers decided that they would use snake_case. I (and again it’s a generic default) use PascalCase for classes in OOP languages. Then, for constants, as @whileTRUEpass said, it’s a general convention to use CONSTANT_CASE (I don’t actually know what this one is called and I don’t have time to search it up). Here’s a great article that might be interesting to read through!


C uses snake_case too (but I do things JS-style (camelCase), probably because I learned JS first).
Interestingly, I do snake_case in JS

Well, things get also worse when you start looking ay languages using Capitalised names as way to control visibility in imported modules … So imagine:

Python - snake_case for variables, camelCases for functions, CamelCases for Classes, descriptive naming

Go - camelCases for everything, CamelCases for exportable, short naming

I use both and they could not be more different. So apart from constants all CAPS, I am with @MattDESTROYER on this … either use your own preference or the one work forces you to use. Just use spaces and never tabs :slight_smile:

1 Like

NO WAY. camelCase is the best.

1 Like

There is no best. There is personal preference and work preference … till you do thngs alone the problem is not there :slight_smile:


For me*. Sorry, forgot to put that in there lol

1 Like

Out of curiosity, why do people prefer spaces over tabs? (You can probably guess I use tabs.) I mean, just theoretically, a tab takes up less space in a file than multiple spaces (of course that’s not really a great reason to use them).

This is a religious question … and most IDEs convert to spaces anyhow.
It is pushing one key vs precise control.
Truth … it does not matter and avoid arguing with space or tab fanatics :slight_smile: just say yes yes

1 Like

So there’s not really any reason to choose between one or the other, purely personal preference? It’s interesting, cos I always thought I was just a stubborn kid who refused to use spaces despite them being the ‘proper’ indentation method. Because I was intrigued, I asked the all-knowing non-sentient behemoth; Google. The first two results (and these will likely be different for each person) were contradictory:

Personally, I think these articles aren’t the best for comparison. The first is interesting and looks at both sides while the other is clearly incredibly biased and written by a so-called zealot the former article warns of and doesn’t (as far as I saw) actually provide any evidence towards its claim other than a theoretical 9% pay difference (which frankly is a weird statistic and I’m not honestly sure of its validity).

So I guess at the end of the day my quick google search agrees with what you said; definitely a religious question, and definitely preference based :slight_smile:

1 Like

Look for the episode of Silicon Valley about it … sums up things nicely :slight_smile:

1 Like

On my robotics team, we do constants in camel case, but starting with a k, like this kMyReallyCoolConstantThatHasAnOverlyLongName The k means constant, so it is easier to identify which variables are constants.

Ok but what if the name of the var itself starts with a k? Would it be like kKangaroo? I feel like people would easily get confused and think it was a typo and try to fix it. Idk

I don’t see what’s wrong with kKangaroo? Also a real var name would be more like kAzmuthEncoderTicks or something like that. Not many cases would even start with a K.

1 Like

That is the worst habit you can get.
As long as you program with friends or solo is ok. But if you ever want to share code or program for jobs also if part time, please avoid using homebrew conventions. Just a friendly advice.


Ok well the team is an actual organization and we literally all do it. So I guess we are all bad programmers? :grimacing: Also this is just how things were when I joined. Take a look at this snippet of our constants file from 2022.

public static final class VisionConstants {
    // Actual 2022 Constants
    // + is left
    public static final double kHorizAngleCorrectionDegrees = 0.0; // -1.25 deg
    public static final int kCircularBufferSize = 10;
    public static final int kBufferLookupOffset = 2;

    // Vision test for failure const
    public static final double kTimeForVisionCheck = 1.0;
    public static final int kNumOfVisionChecks = 10;

    // Old 2020 Constants
    //    public static final double kMinContourAreaSize = 100;
    public static final double kVerticalFov = 0.4939; // old 0.6056
    public static final double kHorizonFov = 1.012; // 50.8 //146 //radians 1.012 // deg 57.999
    public static final double kLookupTableToLensOffset = 0.4959;

The way we use it, it’s not really that bad for the programming part, and it’s all separated into another file so whenever you use it you do this: Constants.VisionConstants.kSomeVariable or import the vision constants and do this VisionConstants.kSomeVariable, but I guess I can see why it’s not great to use.

This is not about being good or bad programmers. Just avoid habits that will be thought to get rid of when you are older … if this is what you want to keep doing not just for fun.
Still you are 16 right …, you probably have 10+ years before an habit is thought to change. Plenty of time