IT/Software career thread: Invert binary trees for dollars.

You can get around doing null checks by creating some kind of pass/fail architecture around whatever you're doing, but null checks are more built into the language and easier. It's like the difference between building a rear facing camera that will buzz when there is a chair behind you vs simply looking behind you as you sit down to see if there is a chair there.

Next edition of Clean Code review. I went through the comments chapter which I disagreed with nothing about. The author was very much about minimal usage of comments.

Clean Code_sl said:

Verbs and Keywords
Choosing good names for a function can go a long way toward explaining the intent of the function and the order and intent of the arguments. In the case of a monad, the function and argument should form a very nice verb/noun pair. For example,
write(name) is very evocative. Whatever this "name" thing is, it is being "written." An even better name might be writeField(name), which tells us that the "name" thing is a "field."

This last is an example of the keyword form of a function name. Using this form we encode the names of the arguments into the function name. For example, assertEquals might be better written as assertExpectedEqualsActual(expected, actual). This strongly
mitigates the problem of having to remember the ordering of the arguments.

Click to expand...

I try to make all my functions verbs, ex: getName() rather than name() so I agree with the first part.

But I think encoding the arguments into the function name (Ex: assertExpectedEqualsActual(expected, actual) ) is completely retarded. Not only is it copied information, and makes for longer function names (which can cause errors because multiple functions with slightly different names will blend together) but I don't think anyone should be able to expect to know what a function needs without looking at the parameter list.

Clean Code_sl said:

Breaking Indentation. It is sometimes tempting to break the indentation rule for short
if statements, short while loops, or short functions. Whenever I have succumbed to this
temptation, I have almost always gone back and put the indentation back in. So I avoid collapsing
scopes down to one line like this:

I prefer to expand and indent the scopes instead, like this:

Click to expand...

This is something I don't feel too strongly about, but recently (The last few years I guess) I've been doing more and more of, especially in classes with many one-line functions (Ex: A class with many getters/setters). I understand that not everyone likes it because they see a function's definition is on one line they may skip it over, but I like having code that is condensed so I don't have to scroll all over.

And finally, something else I agree with that I see a lot of now and then.

Clean Code_sl said:

Sometimes programmers will put special comments on closing braces, as in Listing 4-6.
Although this might make sense for long functions with deeply nested structures, it serves
only to clutter the kind of small and encapsulated functions that we prefer. So if you find
yourself wanting to mark your closing braces, try to shorten your functions instead.

Click to expand...

When closing brace comments help it's a sign you need to extract your functions out. But most of the time I see it (Ex: everywhere in this example) it adds no value at all.

ShakyJake_sl said:

Something that has become a great annoyance of mine lately are void methods that accept a parameter and mutate that parameter without any real indication of it doing so. In C# you can specify an "out" or "ref" along with your parameter that indicates that something will (possibly) be changed with that parameter object. "ref" isn't necessary for objects that are already passed by reference, but it's still a nice indication that your method is changing the object in some fashion.

Click to expand...

C++ has a mechanism to handle this called "const correctness". Basically if you have a function declared as:

void saveToDatabase(std::string & data);

That data string can be modified. If the declaration is:
void saveToDatabase(const std::string & data);

Then the data string can't (there are ways around this of course) be modified. A set of code is called 'const correct' when all parameters have const on them (or are passed by value, ex: void saveToDatabase(int value, const std::string & data)) except those that are modified. So anytime you see saveToDatabase(std::string & data) you're notified that data will be modified by the function in some way.

If a reference to a class is passed in by const reference, then only functions marked as const can be called on it. And if a function is marked as const, then member variables inside those functions can't be modified. (There's ways around this too).

All the code I write is const correct, and I get uppity when others' code isn't.

Tuco_sl said:

C++ has a mechanism to handle this called "const correctness". Basically if you have a function declared as:

void saveToDatabase(std::string & data);

That data string can be modified. If the declaration is:
void saveToDatabase(const std::string & data);

Then the data string can't (there are ways around this of course) be modified. A set of code is called 'const correct' when all parameters have const on them (or are passed by value, ex: void saveToDatabase(int value, const std::string & data)) except those that are modified. So anytime you see saveToDatabase(std::string & data) you're notified that data will be modified by the function in some way.

If a reference to a class is passed in by const reference, then only functions marked as const can be called on it. And if a function is marked as const, then member variables inside those functions can't be modified. (There's ways around this too).

All the code I write is const correct, and I get uppity when others' code isn't.

Click to expand...

Const correctness differentiates noobs from people with even a tiny bit of c++ skills. Of course it also leads to massive amounts of time spent tracking down a bug if your code is heavy on inheritance.

Anyway, its language flame war time!

The 2015 Top Ten Programming Languages - IEEE Spectrum

TIOBE Software: The Coding Standards Company

R is moving up

Celestein_sl said:

I seriously don't get the appeal of R for "big data"... it's single-thread limitation is just a gigantic bottle neck when your data is actually "big".

I remember I had to write some functions in R to do an analysis over 1.7TB of data, and it was just insanely slow. I re-did it later using parallelism in Clojure and it was 3 orders of magnitude faster. Like, I wrote the R, then seeing the estimated competition time, I re-implemented some of the libraries I used in Clojure, then re-wrote the functions, then executed it and got the result, before the R code finished.

I understand that the syntax and tools are a big part of R, but a lot of languages have tools of similar quality without the big drawback. If you're dealing with data in the size of GB then it's not gonna really matter, but for actual "big data"(and 1.7TB isn't even really big...) it becomes a major problem.

Click to expand...

Its true, R is terribad with large amounts of data, that is what Rcpp is for. The popularity is due to the fact that the packages are unmatched. Python is the second closest language in terms of data related capabilities and its not even close to R in terms of quality/quantity of libraries. R is updated fast with new techniques and is updated by statisticians where Python is updated by programmers. Also R hashad.co.nz.

Celestein_sl said:

Honestly I think you're pretty much spot on wormie and that's probably why I don't like it. R is built for statisticians and I'm really just a programmer in that duality. If I'm doing stats work I'm doing it for a very focused purpose where things like performance actually matter a lot, so there are better tools *for me*, but not for a statistician.

My frustration comes with R being used by people who essentially fall on the wrong end of that spectrum for the wrong purposes.

Click to expand...

Curious why not use Weka and/or Mahout if you are using clojure? Why R?

Celestein_sl said:

Cobol is only going to become more relevant, I taught myself Cobol a few years back specifically so I could get that sweet sweet legacy code money as everyone retires. So far it's worked out pretty well, about 1/5 of my clients(but about 3/5 my consulting/contracting income) if from legacy Cobol and Fortran jobs. You can charge some ridiculous rates because they simply don't have many options.

Click to expand...

Guess I should start looking for those Cobol contracts then.

Speaking of Cobol. My father in law has been programming in cobol since mid 80s with a 5-6 year break in between. He recently decided to quit and became a realtor. Crazy bastard, so much skill wasted.