> It's one of those typical things that novice programmers fret about.

I think you might be generalizing a little too far here. I've been programming for over thirty years in more languages than I care to remember. Every so often a meme of some sort raises to the surface and the sheep jump on it. Hungarian notation was probably one of the ugliest of all. Case sensitivity is another. And, case sensitivity added to camel case just makes your job that much harder for no good reason at all:

autoDetectMotorPhaseAngleAndSpeed

Is horribly unreadable and gives you many opportunities to make a typing mistake and cause development delays.

auto-detect-motor-phase-angle-and-speed

Is super-easy to read and type. Less entry errors and legible code are important. If you think that this is a newbie "mistake", well, they are right.

Any actual research to support that, or is it just an opinion?

As I can't find any data, I've asked on programmers.stackexchange.com. http://programmers.stackexchange.com/questions/186407/are-th...

Let's see how long that one stays open! :-)

From one of the answers:

"results indicate a significant improvement in time and lower visual effort with the underscore style. The interaction of Experience with Style indicates that novices benefit twice as much with respect to time, with the underscore style."

Having said what I said, I'll program in any language and abide by any convention if required. That's just what you have to do as a programmer. No issues there. If a client requires camelCase, so be it, it's not like it is crippling.

If I have the freedom to do so, I tend to be very pragmatic about my own projects. I don't subscribe to fads both in my personal life and in software development. Camel case and Hungarian notation are just fads that, when surfaced, may or may not survive the test of time. The second, for the most part, did not. We'll see what happens with Camel case. None of this crap is necessary to write good code, or code that is bug-free, or code that makes you money.

Life goes on. Those who love to camelCase, hey, it's OK, not the end of the world.

> Consistency within a code base is much more important than which style is used exactly.

I know this is a commonly held belief, and I held it too for a short while. But then, I was managing a project that ran on both Linux (lower_case_name libraries), Windows (CapitalizeEachWord), had components in Python (ClassesAreLikeThis but variables_like_this), Java (camelCaseIsAnAbomination) and even some VB6 (don't even remember the convention).

Utterly inconsistent. And it didn't make any difference to readability or maintainability, once people accepted that there actually is no single standard we can use.

In my opinion, it's one of these things like, e.g. significant whitespace or C brace style, that people believe make a difference because they have an example - in which the difference is often not attributable to the feature being discussed.

Well within several modules of the same project, I guess it's inevitable, and not that problematic, especially not between several languages; but seeing (at the top of one function)

int my_counter; char hostName[256]; double LIFESPAN;

doesn't make for pleasant reading, I'm sure you agree.

But in a large enough project, there are several modules that cannot escape that:

Our main codebase used unix_conventional_names. Then, a GUI (FLTK, C++) was added, with classes like Fl_DoubleWindow; Every GUI part now had two conventions.

Then, it turned out that the abstractions FLTK gave on Windows needed a small nudge. So we added some Windows-specific stuff; that module had calls like FLTK Fl_RadioButton, Win32's TrackMouse, our main code's "user_action_t".

Then we added needed to add Python scripting (implementing a native Python module in C) - and since the most maintainable way to do that was to have the C names and Python names correspond, there's a module that also had Python convention names in it. Lather, rinse, repeat with JNI.

So, I would guess ~ 70% of the files ended up being "uniform convention" (with one convention, depending on source code language), and 30% had mixed conventions of up to 4 conventions.

And it didn't make anything a little bit unreadable. It's no more distracting than changing fonts in a document every paragraph (and occasionally in the middle of a paragraph) between several readable standard fonts (arial, courier, consolas, ...). It looks weird and bothering for the first few days, but is not actually distracting or hampering in any way.

And if anyone is going to reply "but new people who come into the codebase will be confused" - that codebase was moving millions of dollars per day, and was nontrivial enough that I wouldn't allow anyone to commit a change on their first week, often their first month, without two other people reviewing it (experienced people got only one person to review their code).

By the time anyone knew the code well enough to make a change, they weren't bothered by the multiple conventions either.

> doesn't make for pleasant reading, I'm sure you agree.

only lifespan, the upper case implying constantness when it isn't, bothers me. Other than that - pleasant as day.

those are essentially different code bases (python/java/vb6).

As the other replier wrote, having different style variables and naming conventions in the same project - really, the same file - is somewhat distracting.

<?php $x = 55;

$numberOfPeopleEmailed = 23;

$What_The_User_Chose = $_POST['chosen'];

do_something_withVarName($x);

$sFirst_Name = _$_POST['name'];

it gets distracting. While it's been rare for me, I've occasionally dealt with large files with different styles of var naming contributed by different people. It's far more of a mental nuisance than tabs-v-spaces (I'm a tabs guy, fwiw).