Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

Protip for beginners: If your supervisor has created this legacy code and you make it into something good, prepare for passive aggressive backlash.

"Stop trying to communicate and just communicate" is actually career-changing advice.

Sometimes code isn't re-written because it's "bad". It gets re-written because somebody has a different opinion on what "good" and "bad" code is. You don't necessarily end up with "better" code. You end up with different code. Rewrite culture is definitely a thing.

7:50 bad code example 9:18 problem: 14:00 fizz buzz basic code 19:52 table lookup way 20:22 problem: havent got rid of the second check 21:05 answer in JS version 22:45 Cargo cult programming 32:33 is too many imports in your code a bad thing 33:38 avoid long imports by using wildcard 38:30 another aspect of Cargo cult programming 45:04 46:37 ConfigurationManager 47:43 Configuration is way better 47:48 ConditionChecker 48:40 Condition is way better

"All roads lead to stackoverflow". Yup

"It's a stringly typed system"

"There's a lot of developers who can't program." True. There's a lot of programmers who can't develop, too.

I worked at a company with a guy who committed almost every enterprise programming sin mentioned in this. He was absolutely obsessed with making wrappers and abstracting the most basic functionality into monolithic classes. If I every asked him why he was doing it, he would tell me that it is "good design".

11:09 "Sometimes when you approach the problem from the wrong angle, you can really make it something of it" is so relatable.

I disagree with the point on imports. The only time I ever look at imports is when I'm reading someone else's code, and in that case I want to know exactly what package a specific class is in. Using * imports would mean I have to guess which package it's coming from, or I would have to have the project loaded in a tool that can calculate dependencies for me.

Frankly, if your code has too many imports, the issue isn't that you should be using wildcards. It's that your class is doing too much all by itself. Half the reason it's recommended that you import everything explicitly is exactly so that you can identify it as a code smell.

Speaking of code commenting. In school, high school or college, it seems in the beginner programmer courses the teachers are quite adamant about adding comments. In high school, they just don't add comments and so the teacher pounds it into their head to document every line. In college, the comments may be sparse among the spaghetti code that gets turned in. The professor comes back with "add more comments," and docks points. I had dev experience when entering the beginner Java class at university and, of course, commented the necessary lines and it was a nice bit of code. The student aid came back with "add more comments." Oooh, boy... did they ask for it then!

Wildcard imports in Java would be nice if they didn't cram so much into every single package. Seriously, it feels like they just use the java.util package as a dumping ground for anything they didn't already have a package for; it holds pretty much every data structure in the entire language plus a few other arbitrary features like Currency and Date that have pretty much nothing to do with anything else. The other major issue is that wildcard imports erase the data of where each class you're using actually came from. This isn't an issue with the standard library, but it can get pretty bad with large codebases importing code from other packages in the same codebase. Without IDE indexing features it's basically impossible to figure out where any class in a file with wildcard imports came from, which isn't very nice generally.

Quite entertaining video, but the guy sure loves to talk a lot, his verbosity can easily outmatch verbosity of the code he was bashing at some point.

"We don't touch the sacred defaults." I must really be a heathen as that's usually the first thing I change.

I like seeing: /* * The id of the object. */ private int id;

Having only started with Objective-C(++) less than a year ago, I lost count how many times I wanted to look up and strangle the person who came up with that language's naming convention. "Nonono. Having a function doThing(ArgType):arg and another function doThing2(ArgType):arg (Arg2Type):arg2 is bad. You should call these functions startThingDoerWithArgument(ArgType):arg and startThingDoerWithArgument(ArgType):arg andSecondArgument(Arg2Type):arg2 " - some daft maniac who really likes poetry, I suppose. The only reason why we stuck to this style for our iOS code is because other iOS developers expect this style. Repetition does indeed increase truthfulness. No wonder people have huge full HD or 4k monitors these days. It's in an attempt to fit method calls on one line.

I love how almost each and every video in this channel is simultaneously educating and entertaining!

The problem is often not so much the variable name but because your code does too many things so you have difficulties finding simple names, and often, I feel, it indicates much required refactoring / decomplexification instead of renaming. Renaming can't help you there.

22:14 " ...and we've reduced it to its essence, and we can wander around feeling mathematical, functional, and remarkably cool, and also very certain of our jobs. So there's this other side to Enterprise Programming that we see in a number of cases, and again I want to refer to this point as being Art: It's clearly a unique result of a unique temperament... "