Case Conventions

>>61100450
camel case is the obvious winner

but also, this is the type of stupid semantics argument that is a huge waste to put any human time into considering

i like camel

camel. pascal is fine too but snake has to go

>>61100475
Why does everyone always hate snake case?
Is it just because of the underscores?

>>61100499
yes. its fine in certain places but not as the regular case

>>61100450
camelCase is the most convenient and easy to read and type, PascalCase is fine too

idk how to program so idk

I use different case conventions depending on the language (snake_case in C, camelCase in C++, for example). Fight me.

camelCase for datatype names and method names, PascalCase for anything in hierarchy above methods, snake_case for final datatypes. that's how my compsci teacher back in highschool did it, it kinda just stuck.

>>61100784
This is in Java I may add

>>61100450
what does PEP-8 say?

>>61100450
Snake, nothing else.
>>61100519
There's nothing wrong with_underscores.

>>61100450
snake_case for variables
camelCase for methods and functions
PascalCase for classes

>>61100519
but it's easier to read

a_really_long_variable_name
aReallyLongVariableName

snake_case is far an away the easiest to read, plus it allows you to use capitals however you want

>>61100911
Seconded

>>61100450
snake

camelCase

>>61100773
this one gets it

>>61100911
Exactly

>>61100450
no-kebab-case?

what about LISP-CASE?

>>61100450
>>61101328
I prefer SCREAMING-KEBAB-CASE

>>61100450
It depends on whether I use tabs or spaces and on which line I put an opening curling brace.

>>61100450
PascalCase for functions, camelCase for variabes, snake_case for namespaces and classes, SNAKE_CASE for constant variables.

Anything else is shit and you should die in a fire if you do any different you stupid faggots.

>>61101353
If your namespaces are so long you need a convention for it, kys.

>>61100450
It depends.

ClassNames
methodNames
variable_names
GLOBAL_VARIABLES

>>61100924
Maybe if you're a tard

(defun lisp-case () 
  (write-line "SUCC")) 

>>61100450
lisp-case

>>61100450
The conventions you use should reflect the language you're using.

Personally I like PascalCase classes, camelCase functions and snake_case variables.

I use Hungarian Notation

>>61100450
Depends on the language best practices. I myself grew with camelCase so that's the most comfortable for me

I'm growing fond of snake_case from working in SQL for a while. It's great because things are so readable and can have things like acronyms in them and still be understood.
>GPAVsCost
>GPA_vs_cost

>>61100853
Pascal case for class names
Then variables are camel case and snake case depending on if the variable is local or not

>>61101418
>methods aren't variables
Cuck language

>>61104023
>storing binary code into the stack
Eww...

camelCase for everything except C, which should always be done in snake_case.

>>61100450
mixed_Case

>>61100450
camel case requires the least amount of effort. you only have to press shift once...
in pascal case you have to press shift twice, while in snake case you press shift and - to make that extra _

>>61104131
I'm sure you're really productive with those 20 seconds you save every year

>>61104180
i appreciate your comment.

>>61100450
Depends on language.

fuckyoucase

>>61100499

an underscore takes too long to write when intellisense doesn't register that it should be popping up.

>>61104541
>intellisense
KYS.

>>61104429
fuckyoucase is only a fuck you if individual words are subsets of other words, cause then, you can't really write a dictionary parser to make it legible.

>>61104429
>fuckyoucase
snake/Camel/hungarian?

int f_Y_cint16u(int S_uCc);

Apps Hungarian: Why??
Because apps hungarian forces you to write variables with *purpose* and later identify them in code.
Now System Hungarian is a idiocy that could _only_ be invented in a retarded place, a.k.a The Microsoft Windows division

PascalCase for functions.
All caps for macros.
camelCase for variable names.

>>61100450
unixcase

>>61100450
Sticking to standards >>>>>> your opinion.
I shouldn't have to deal with your personal bullshit if I have to read your code.

>>61100450
camel case for variables
snake case for symbolic constants: e.g

#define SOME_CONSTANT 5

int firstNumber;

>>61104013
That sounds like a lie or rather an incomplete truth. Below is an exact quote from PEP8:

>Function names should be lowercase, with words separated by underscores as necessary to improve readability.

>mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

>>61103691
g_oKillYourself

>>61100773
I use camelCase in C. It's shorter.

>>61104637

typedef const unsigned int C_U_N_T;

>>61100450
camelCase or snake_case, depending on language and codebase conventions

PascalCase is retarded

>>61106598
What a dumb inconsistency clause

>>61100450
Camel for Java or JS, PascalCase for .NET, snake_case for C and C++.

>>61107014
>What a dumb inconsistency clause
You've just summed up Python beautifully

lowercase

stop giving me rsi

>>61101353
Titlecase for typedefs and constants, UPPERCASE or Titlecase for macros, lowercase for everything else

>>61101316
i fucking hate that faggots who says "exactly"

>>61104694
Apps Hungarian is a band aid for a language which has an inadequately expressive type system. It is, however, useful.

Isn't the rule at least for .NET languages PascalCase for public stuff and camelCase for private?

i pretend im using registers and comment what each register does at the header

the correct answer is camelCase for private, TitleCase for public

this applies to variables, methods, and classes

>>61105017
Fuck you faggot, it's my code, not yours. I wrote it, not you.

>>61100450
PascalCase for class and struct names.
snake_case for variable and function/method names.
camelCase never.

camelCase looks fucking retarded.

how can you faggots deal with pressing shift so often?

>>61100450
snake_all_day_every_day
fuck_the_other_two

>>61100450
>idk how to program so idk
Look you're halfway there
<faggot>
<idk>how to program so</idk>
</faggot>

>>61100450
>PascalCase, camelCase, or snake_case /g/?
Only sane answer, depends of the language convention.

int c_case;

(define lisp-case)

less ThisVerboseJanglyShit() and more this()

category_datatype_camelCaseDescriptionOfVariable

camelCase is comfyCase

File: 1497561813199.jpg (90KB, 604x453px) Image search: [Google]

90KB, 604x453px

PascalCase and camelCase are for hipsters desu

File: 1497469820975.jpg (36KB, 500x500px) Image search: [Google]

36KB, 500x500px

UPPER CASE
lower case
Title Case
camelCase
snake_case
kebab-case
Train-Case
ǝsɐɔ ʇɐq
çt̶̀͢͞h̴̷̨̡̕u̴̸̴l̡͜͞u͜͠ ̡͜͝c̀͞á̷̧̧s̷̀͠͠e̸̶͟
Sentence case
PascalCase
YELLING_SNAKE_CASE
YELLING-KEBAB-CASE
brokenspacebarcase
Briefcase 

>>61100924
easier to read on its own but harder to read as a whole

some_type_or_another variable_name_goes_here = new the_type_of_it(some_argument, another_argument)
someTypeOrAnother variableNameGoesHere = new theTypeOfIt(someArgument, anotherArgument)

>>61110261

NuTcAsE

Le>maYmaY<Caz3

Is the best

>greencase

>>61112585

Penis *p = emalloc(sizeof *p);

>>61112585

someTypeOrAnother variable_name_goes_here = new theTypeOfIt(some_argument, another_argument)

>>61112943
You can only create variables using upper or lowercase letters though

Depends on the language, project, and what I'm naming, but in general I prefer snake_case for most common use cases.

File: imply.jpg (208KB, 1024x768px) Image search: [Google]

208KB, 1024x768px

>ebayReimport?
>eBayReimport?
>eBayReImport?

Fuck that, just use ebay_reimport.

Fuck if I know. I use whatever I feel like at the time and sometimes it changes. Analogy: it's like correct capitalization in English; maybe you look illiterate not doing it but only regards actually have trouble understanding it.

Far and away more important is breaking up your functions into tiny legible pieces. Analogy: this is like making paragraphs in English.

I can read straight lowercase all day, but give me a wall of text and I will skip that shit. Similarly, if the function is only like 8 lines in average ain't no one care what the case is. But a monster switch case or a billion if elses or a single-function program that's 10,000 lines can just suck a dick; I don't need that in my life.

>>61115726
*retards, god DAMN it

>>61100450
snake_case

What would cuck case look like?

>>61115783

8=====D~~~

camelCase for variables
PascalCase for function/class/struct/namespace names
UPPER_SNAKE_CASE for compile-time constants

>>61100450
kebob-case

camelCase are for retards.
that's why Linus and other brilliant people use snake_case

snake_case for Python, camelCase for C/C++, PascalCase for Java.

>>61100450
Depends on convention of the project i'm working on. On my personal stuff, assuming C:
variables_functions_and_internal_structs
StructsEnumsAndUnions
MACROS_NO_GLOBALS_EVER

I think we know the more important question.

int  *foo;
int * bar;
int*  baz;

>>61118669
int*
or do you also write "in t" or "flo at"? Asterisk is part of type.

>>61118829
it's part of the declarator, not the type specifier. Together the type is deduced.

int* x, y;
// parsed as int *x, y;
// x is an int*, y is an int

>>61100450
WHATEVER_THIS_IS for constants
SnakeCase for classes
camelCase for everything else

>>61118845
One line for each declaration, all problems gone, it's clear what the type is.

>>61118979
There remain inconsistencies.

int arr[4];

I think you'd agree that the type of arr is int[4], but the array notation is not part of the type specifier.

>>61100450
Whatever format i copy in stackoverflow

camelCaseIsGreat

>>61121151
>camelCaselsGreat

>>61121151
brilliant

>>61100450
rAnDOmcAsE

File: 1472324760648.jpg (580KB, 1080x1300px) Image search: [Google]

580KB, 1080x1300px

>>61100450
snake_case is the only true way, because many non-latin alphabets don't even have uppercase letters to do PascalCase

Example, you can't write Go code properly using hiragana, because only names starting with uppercase are considered public. Hiragana names are always private.

tl;dr Go sucks ass

>>61122076
some men just want to watch the world burn

>>61100450
If there's an established convention (like Java or PEP-8) - use it.
Otherwise, PascalCase for classes/type names and camelCase for everything else, including functions.

>>61122275
>needs an example
>pulls up japanese
>when japanese programmers don't even program in japanese, but english
kys weeb
Go does suck, but not because of your autism

>>61122275
>having anything but ASCII for your code
When your encoding goes to shit you will only have yourself to blame. In my experience, all non-english comments get corrupted somewhere along the way.

lower snake_case everything except global variables / constants which upper SNAKE_CASE.
Only dumb pajeets use anything else.