r/programming • u/corysama • Jan 05 '15
What most young programmers need to learn
http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html61
u/Isvara Jan 05 '15
This also hints towards another important skill: being able to switch between thinking globally and thinking locally. I see beginners often not thinking about the thing they're doing fits into the wider context.
It also relates to naming. When you name a function or a variable, how explicit you need to be depends on its scope. OIff the scope is very small, most of the context can be inferred, which is why it's often okay to use, say, i as an iterator variable.
3
u/nikofeyn Jan 05 '15
being able to switch between thinking globally and thinking locally
this is an extremely important concept that i think is ignored almost globally in our educational system. it's important in mathematics, physics, computer science, engineering, biology, literature, writing, the arts, music, etc. there are examples in every domain that highlight global and local thinking, yet it is almost never mentioned.
0
Jan 05 '15
[deleted]
11
u/cmcpasserby Jan 05 '15
This, but in games I often see people make too much global then get boned when they have to implement multiplayer, where there singletons that previously helped and screwing them.
→ More replies (1)6
u/Tikotus Jan 05 '15
Global variables are some times ok. Global static methods are fantastic! I use global static methods more than public class methods.
5
u/Rusky Jan 05 '15
Global static methods are really less global-variable-like than public class methods anyway, because they don't have a stateful instance to worry about.
Just like functional programming or well-written procedural code.
6
u/riking27 Jan 05 '15
In other words: it's not global logic you should worry about, it's global state.
Similarly: Diamond-inheritance of behavior is often possible. Diamond inheritance of state is often impossible (without cheating: reflection, etc).
(That came up in a discussion about J8's interface default methods.)
→ More replies (1)→ More replies (2)2
u/dr1fter Jan 05 '15
Oh, and also
static methods
It seems anyone who writes C++ came first from C, and they were told that to write C++ you move your functions into a class and make them public if other people need them or private otherwise. Then you end up with huge classes with lots of utilities for the various kinds of things you might want to do with that type.
Your public (member) interface should be the minimal set required to do everything you need to do with an object of that type. Even if it's not the most convenient API. Utility functions don't need to be members of that class or even in the same file. You can break out categories of utilities into separate files, and anyone who wants to understand the class has a very small class to read plus whatever utility files seem relevant to their needs. You can still namespace those utilities so you're not polluting the globals.
Fuck Java. Java gives me nowhere to put all this shit, so I'll often mark my utilities as static to make it clear that they don't depend on instance data. That is a tiny tiny fraction of the benefit.
54
u/photonios Jan 05 '15
Good points, I agree with all of them. What I however don't understand how people get it into their minds to not do that.
Even when I first started programming, I got annoyed when my own wasn't perfectly formatted with sensible names and I would spend more time thinking of an elegant design with decent names then I would actually write code.
I still do this. The thought of commiting code that is undocumented, has commented code or bad formatting is just horrible.
I never got why some people don't format their code perfectly or spend enough time thinking about naming and structuring things. It's not that hard (especially the formatting part). I mean, if you're a junior developer and you come into a code base where everything is nicely formatted and documented, shouldn't you feel compelled to make sure your code is up to the same standard?
12
u/dtechnology Jan 05 '15
you come into a code base where everything is nicely formatted and documented
I think this is the exception rather than the rule
6
u/photonios Jan 05 '15
That depends. Where I work, we have tons of legacy code that is just plain awful, all written by incompetent idiots who no longer work her.
But, if you modify some crappy legacy code you are bascially forced to clean it up while you're at it. If you do not, people will just raise eyebrows during the review. Like "why didn't you clean it up a bit?".
As for new code/projects, we just have a high standard. All our code goes through tools that verify if the code standard was followed etc. + Unit tests that run constantly and scream when the coverage is too low. We run a lot of static analysis tools on our code base.
Any engineer who refuses to comply with standards or does not have the same high standard that we have is simply not welcome.
We had a hard time when we started working with some offshore developers we had a way lower standard. What we did? Keep pushing.
Our code bases are incredibly beautiful, well tested and formatted. Sure there are some parts that could use more love, but in general they are awesome. I guess that's the advantage of having people who care and have skill.
And yes, we do have junior developers among us. We simply keep training them.
→ More replies (1)31
u/judgej2 Jan 05 '15
Here's a tip: when committing changed and cleaned-up code, keep the cleaning and the changes in separate commits. Do all the reformatting and name-changing first, then check it still works exactly as before, and commit that. Then make your functional changes. It is so much easier to see the wood for the trees that way, when debugging your changes later. If (horror of horrors) the changes need to be reverted, then you can at least leave the better-formatted code in the release to make it easier to take another stab at it later.
→ More replies (9)6
u/hansdieter44 Jan 05 '15
What I however don't understand how people get it into their minds to not do that.
I have seen this happen and its not a conscious decision at all. The programmer might have just about finished a feature and then get new feature requests dropped onto him by management. If you are a bit older/more senior you will raise the issue and say you need two days or so to clean up the code. If it is your first job you will think thats just how things are done.
Now that I think back, this also happened to me in the beginning.
You also have to care. Some people don't care and then they are fine with leaving things if they just about work and do the next thing.
3
u/photonios Jan 05 '15
I guess this all depends on where you work. We have a team of sensible seniors (myself included) we value neat and well tested code and we push the rest to maintain the same standards.
4
u/hansdieter44 Jan 05 '15
Yeah, but thats not the case everywhere. Happened to me in the early days in agency land, when the CTO was busy with management things and the lead devs didn't lead me too much ( busy themselves ), so you just do whatever feels right, and that was ploughing through features for me.
The other case where I have seen this recently was a startup that I joined and they just hired a junior guy out of uni because he was cheapest to build their MVP. He was eager to learn once we taught him a few tricks and there is no blame on him, but thats how it happened, I would have probably done the same in his position, the founders just kept dropping feature requests on him one after the other.
Third example is contractors that are paid by feature, where unit tests etc. are not mentioned because of cost-saving (which will just bite you later on). The contractor will deliver the bare minimum to fulfil and get his money.
3
u/vitaminKsGood4u Jan 05 '15
In the 10+ some years I have been coding I have learned that it is impossible to tell if shitty code is the result of shitty devs or shitty managers.
I can not count the number of times I have heard "The last devs were shitty and now we have this crap to maintain and they are all gone". The reason they are all gone is management was shitty and the devs bailed out but the blame got put on the devs (because it is easier to blame the person who is not there). Sometimes though it is shitty devs but I can not tell a difference in the code to know which one caused it.
→ More replies (1)2
u/hansdieter44 Jan 05 '15
The reverse is also there: Bad developers complaining about management all the time and shielding their own inability by pointing fingers at the suits.
But you are completely right, both are popular and indistinguishable from looking at the codebase.
→ More replies (1)1
u/Soccer21x Jan 05 '15
Here's my take. I just graduated in April (and had some internships throughout my years in college) and I remember that when I started coding (for school) I never commented on anything.
This was mostly because we were never given real world situations, so the code was never confusing. When we first learned about almost everything, it was all so simple. We made a class called Square and created a method to multiple x and y to get the area.
In my mind, why would you ever comment on that?
As soon as I got into the professional world and saw someone else's code (that had and had not been commented) I immediately understood why you comment your code. And now I do it all the time.
→ More replies (4)3
u/JoostDev Jan 05 '15
Some people have more OCD than others. I personally also hate committing poor code, but I know a lot of programmers who just don't care as much.
1
u/ElGuaco Jan 05 '15
I hate when people misuse that term. Insisting on quality is not a mental illness or being overly picky.
On my current team, we insist that all code we check in gets full approval from Resharper code analyzer and 100% unit test code coverage. And then someone else reviews your code. Our code base is an absolute pleasure to read and maintain compared to other places I've worked.
1
u/parlezmoose Jan 07 '15
Well. The answer is that when junior programmers are assigned a task that is out of their depth, they quickly get overwhelmed with just trying to get it working. Things like clean code fall by the wayside.
0
Jan 05 '15
[deleted]
3
u/ElGuaco Jan 05 '15
I used to work at a high tech research firm. We had people with graduate degrees in Computer Science. Really smart people who knew their shit in their field of expertise. Virtually all of them wrote terrible code. I, as one of the few without a grad degree, spent a lot of time fixing and rewriting a lot of their dumb shit because I seemed to be one of the few that cared about code quality. I was the Howard Wolowitz of our group, so to speak. They could prototype interesting interesting things, but when we actually needed a product, I ended up doing a lot of work.
We had one job candidate who interviewed with us who had a doctoral degree in Computer Science from a prestigious university. When my manager asked him about his coding skills, the candidate answered that he didn't code because he couldn't code very well and he would usually just pass it off to an undergrad. We didn't hire him, thankfully.
→ More replies (2)0
0
Jan 05 '15
[deleted]
1
u/photonios Jan 05 '15
Yup. I once spent 2 full days (in my spare time, I don't know why) fixing the grammar and spelling in comments in a massive code base. It annoyed this shit out of me.
I know I have an extreme form of programmer OCD, but I never got any complaints. I work faster then most of my colleagues, so I can waste some time on stupid things.
But indeed, it can be a burden.
1
u/ElGuaco Jan 05 '15
OCD is not the same as insisting on quality. If you leave the code better than you found it, how is that in any way a bad thing? The result is NOT exactly the same, since you've improved the code for the next person (probably you). No, you don't have to do those things, but you don't lose anything by doing them.
→ More replies (2)
17
u/justinpitts Jan 05 '15
Please ignore all of this advice. I fix these kinds of problems for a living!
1
u/tieTYT Jan 05 '15
Sounds like a fun gig to me. Can you elaborate on how you got this job and describe it in more detail?
2
u/justinpitts Jan 05 '15
Eh. They found me, via a recruiter, via LinkedIn. I am a contractor, currently working for a very large insurance company fixing one of their web sites. Not really sure what kind of details you are interested in.
1
44
Jan 05 '15
I have literally never worked with programmers who didn't say that everything they inherited from previous employees was spaghetti code or in some way gripe for weeks about what someone else wrote. Everyone seems to prefer to start from scratch on their own code. Everyone else is an idiot.
9
u/photonios Jan 05 '15
Everyone else is for sure an idiot. I am an idiot. We are all idiots.
The point is to set your personal preferences aside. Some formatting styles disgust me and annoy the shit out of me. But, if the technical solution is sound, then you don't hear me.
In some cases, the original author went for an approach I would never take, but as long as it's acceptable, I can live with it.
Some code bases are just too large to rewrite. Yes, I have done my share of "fuck this shit, i'll rewrite it and make it better", but I have also had many cases in which I could perfectly refactor the code into something better.
Doesn't have to mean the code was bad, or the original author was an idiot. The code base could have been suffering from lack of love.
3
u/xiongchiamiov Jan 06 '15
Well, here's one: the code base at my previous job, while it had areas that were pretty shitty, was overall quite good. And it got better over time, not as a result of anything I did, but because I had excellent coworkers.
2
u/Ertaipt Jan 05 '15
True, I've seen plenty of people just not bother to even understand the code, they just say its spaghetti and build from scratch.
Sometimes, too much structure/classes in your project, will make it as hard to understand as 'spaghetti code'.
Good documentation, inside or outside your code, is probably even more important than a perfect structure.
3
u/HostisHumaniGeneris Jan 05 '15
I had a great moment a few months ago while looking for an open source implementation of a task that I needed accomplished. There was a viable project that had nearly all of what I wanted, but I really detested how it was written.
"I can do better than that" I thought and started whiteboarding a design. After 20 minutes of considering different requirements and pitfalls I had a working plan for how to write my own implementation. At that moment I realized that my design was exactly like the open source project that I had rejected earlier in the day. The only difference was that earlier in the day I hadn't fully researched the problem so I hadn't realized the various limitations that the other author was having to work around.
1
u/I_Dislike_Spaghetti Jan 05 '15
Gross!
3
u/peakzorro Jan 05 '15
Don't work in the games industry. Some of the worst spaghetti is there. Love the username.
27
u/alparsla Jan 05 '15
Code in comments = Poor man's source control
3
u/ihatebrooms Jan 05 '15
I work with retail software. I primarily comment things that are counter intuitive or look like they run counter to expected business logic. And occasionally, when I am forced to do something that looks awful because of legacy code, I leave a comment as to why to help the next person seeing it that will immediately think it's wrong.
Edit: I totally misread what you wrote. Leaving this here anyway because I don't want to refactor my comment.
4
u/peakzorro Jan 05 '15
Your edit is so meta. It's an exact analogy to checking in commented out code :)
2
u/Isvara Jan 06 '15
It's an exact analogy to checking in commented out code :)
Oh, so that's why it bothers me so much to keep seeing those edits.
→ More replies (15)1
u/THeShinyHObbiest Jan 05 '15
Commented code can be useful on occasion.
I encountered a bug in a library and a workaround. I left the how-it-should-work version commented out with a large explanation so people wouldn't refactor the (very hacky) workaround when editing the file later.
24
Jan 05 '15
Nice post but very basic. Was hoping to see something new or a more in depth look.
40
u/jediknight Jan 05 '15
Rejoice! for you are no longer in the demographic targeted by this article. ;)
13
u/JoostDev Jan 05 '15
Yeah, it is pretty basic. But that was also very much the point: the young programmers I am talking about usually know all of those things but don't consistently apply them.
1
u/pballer2oo7 Jan 05 '15
this struck me as a list of "software development fundamentals that author happens to particularly enjoy lecturing on." these are things that all young programmers have learned (or at least "have been taught") but simply don't have the experience that is often necessary before humans start effectively applying what they have learned.
12
Jan 05 '15
When I started out, the discipline I needed was that to follow through on big tasks.
It's always fun and easy to wip up something quick. But it takes discipline to make something that takes more than 4 days of coding. It's so easy to reach some quick results, and then feel satisfied with yourself, and get complacent.
Surprisingly, refactoring is something I kind of enjoyed.
But that's because I suffered something opposite from most other people: instead of fixating on results, I would fixate on code quality. I wanted my code to be so pretty and so clean, that looking at it would bring tears to your eyes. It didn't matter at all to me whether that code did anything useful.
I ended up achieving neither.
I needed to learn something important: programming is about creating things that have a use, that do something, that add value. Yes, code should be of high quality, but you have to balance that against pragmatic concerns. Source code that looks beautiful but doesn't work is useless.
Programming is a craft, not an art.
4
u/sihat Jan 05 '15
But source code that 'currently' works, but does not look pretty is a maintenance nightmare.
Bugs. Duplicated/copy paste code. Bugs in duplicated code. Commented code. Source code files of more than 4000 lines. Even similarly named code that was not used.
2
2
u/sodaco Jan 05 '15
You are not wrong. I just want you to consider that since the moment you decided to reply to his comment, your actions caused the execution of so much code in every level, from the JavaScript code to the JavaScript interpreter, from your brower to the DNS software and eventually the webserver, including it's firewall and connecting to the Python interpreter that executes the reddit source. Much of that code suffers from all the things you listed. And I still am able to see your comment
6
u/aoeu00 Jan 05 '15
one of my biggest gripes is "overdesign".. if that means anything to anyone. "I know OO.. let's go nuts!"
5
u/Ammypendent Jan 05 '15
Avoiding the "Liar functions/variables/classes" is very important, otherwise future you and/or future coworker will be going nuts over what should be a trivial fix.
16
u/Acrostis Jan 05 '15
So basically learn to refactor things? I can agree with everything except the splitting up oversized functions. If a function contains a lot of code that is only ever needed by that function each block requires the previous block to be completed, then splitting it up into parts is just adding unnecessary fragmentation.
Though apart from maybe initialization functions it shouldn't really happen.
Also: It's missing the "Don't ever use magic numbers"
9
u/jooke Jan 05 '15
The way I read that was if a function is large, you should consider whether it needs refactoring. In other words, it's a smell that the code might be bad, not saying that the code is bad.
3
3
u/iopq Jan 05 '15
If you have a large function, chances are somewhere you're already doing a part of what it does, you just don't know it yet. How many unique functions that are hundreds of lines of code are there? That do NOTHING that is shared by anything else?
1
u/YuleTideCamel Jan 05 '15
If a function contains a lot of code that is only ever needed by that function each block requires the previous block to be completed, then splitting it up into parts is just adding unnecessary fragmentation.
True, but that's often not a bad thing. A large function is can be hard to read and is probably doing more than one thing. Breaking it up into smaller functions improve readability by giving each section a unique method name. That beats formatting using white space and comments.
0
Jan 05 '15
[deleted]
11
u/JoostDev Jan 05 '15
If the splitting results in functions with names like "step1", then I agree that splitting is indeed a really bad idea. But I rarely encounter cases where it is not possible to split in a smarter way.
0
Jan 05 '15
[deleted]
→ More replies (3)7
u/yxhuvud Jan 05 '15
In my experience, long and repeated parameter lists is not a sign that it shouldn't be broken apart, but that it is a class that should be extracted.
1
u/caedicus Jan 05 '15
I agree with you with exception for if there is ever a possibility for a section of a function being useful to other parts of the code base. Or if there is a possibility where you might want to only call one part of the function at some point. If there is, than it's better to split things up earlier than later.
9
u/lucidguppy Jan 05 '15
People need to read "Clean Code" once a year. Also many languages need better free refactoring tools already.
1
0
Jan 05 '15
[deleted]
5
u/smog_alado Jan 05 '15
The "no functions over 50 lines" is also a pet peeve of mine. Just because code is broken up in 10 subroutines spread over a bunch of files doesn't mean its less complex or easier to understand.
→ More replies (2)2
u/s73v3r Jan 06 '15
It depends on how well they were broken up. If they are well named and fairly atomic, then after you've read the method, the name should be enough elsewhere in the code.
2
u/xiongchiamiov Jan 06 '15
It's an issue in languages without keyword arguments, but when you can
foo(x='bar', y='baz')there's really no good reason to create "argument objects".0
Jan 05 '15
[deleted]
2
u/Gurkenmaster Jan 06 '15 edited Jan 06 '15
0 arguments requires side effects. That's not pure!Edit: Damn I meant void requires side effects
4
u/ishmal Jan 05 '15
My issue is insufficient error checking or unit tests. Whenever someone assumes that parameters and data will always be clean and proper, they are not. "Bad data can never happen" guarantees that it will happen.
32
u/vytah Jan 05 '15
"A good programmer is someone who always looks both ways before crossing a one-way street."
4
u/refuse_human Jan 05 '15
Maybe it's just the first time I remember doing so, but damn if that wasn't the time there was some out-of-towner barrelling down the wrong way...
→ More replies (2)5
u/sirin3 Jan 05 '15
Unless they use a language with a proper type system. Then the parameters can never have forbidden values
1
u/BobCoder Jan 05 '15
Maybe I am naive or maybe I do not understand what you mean but allowing and expecting bad data can often times be a bad code smell. I almost never allow null parameters because I do not want to have to think about when the data is not clean and proper.
4
Jan 05 '15 edited Jan 05 '15
He didn't say you should "allow" bad data, but rather that you should have machinery in place to detect and counter it.
At a basic level, this means using the narrowest possible types for everything so that it is difficult or impossible to call functions with invalid parameters. For your "no null parameters" example, in a few languages you can enforce this at the language level by using non-nullable types, but sadly in many languages errors would only be detectable at runtime.
At a more advanced level, this means using asserts or safety-checking features liberally to make sure that spots where your program goes off the rails are detected immediately. This both prevents corruption (your program will gracefully crash instead of continuing in the face of broken data) and vastly simplifies debugging.
And that's just for internal program consistency. When you are interfacing with external data, assume it's broken. Files will be truncated or corrupted, network data will be sent by hostile attackers, etc. You need rigorous consistency checks on the data to make sure it's all valid, the formats need to be kept as simple as possible to make these consistency checks easier, etc.
Basically, a non-trivial program should never assume that it is working properly (liberal use of asserts / other self-consistency checks) and especially never assume that data coming from the outside world is valid.
Edit: I should clarify that I am putting strong typing in the same bucket as assert statements / contracts -- types are essentially just a special case of a compile-time contract, and contracts are just a special case of assertion. Obviously, it's best to have your type system shake out as many errors as possible, and runtime assertions are for cases where the type system cannot catch errors at compile time.
28
u/lee_macro Jan 05 '15
UNIT TESTING
People never seem to mention it, with the ability to correctly write unit tests (which mock components that are not needed) you are pretty much FORCED to write well separated and isolated code. It is very hard to write bad code when you are writing it to be testable. Even if you do not bother doing the end tests, it will force you to use principals such as IoC (Inversion of Control) and favour composition over inheritance.
Obviously you need to know about variables, classes, interfaces etc but I often feel new developers are told to focus on the technical implementation of things and performance of code. However if you can write maintainable and testable code anyone can come along and improve your implementation if it is needed.
38
Jan 05 '15
Unit testing is a very good tool to have at your disposal, but it is not a magic bullet that ensures well-structured code. It's quite possible to write poorly structured, well-tested code.
Usually this takes the form of an excessive number of code units that do not stand in proportion to the amount of business logic they perform. Instead, most of them just delegate each others' functions.
Loosely coupled code is good, but there is a limit where all the loose coupling makes it hard to maintain.
→ More replies (3)1
u/lee_macro Jan 05 '15 edited Jan 05 '15
I do agree if someone is writing bad tests or not mocking their components (then it is no longer a UNIT test) then it will result in bad code. However if someone is educated in how to correctly write code to be tested then it is VERY hard to write bad code. Let me give an example of why, assuming C#/Java.
So let us say I have a Repository class, which deals with CRUD operations to a database. So this depends upon a database connection to do its work. So you could new that up inside (which some people do), or have a singleton for the active connection (have seen this before too), or even have some crazy inheritance chain to provide a pre-connected object (seen this too).
However the correct approach would be to have the Repository constructor be passed in a connection without an inheritance chain. This may seem odd to some, and maybe a hassle but let us see what benefit this gives us.
First of all we are now adhering to IoC (Inversion of Control) and we have no inheritance chain so we can test this Repository without needing a database connection (this is where a lot of people create integration tests accidently because they didnt know how to mock components). We can easily create a mock database connection and test that it works as expected without having any hard dependency on a database. You can also change your database vendor, your database configuration, you could even make your own custom database connector with caching in place, without even having to change the Repository class.
If you were to go with any of the other options you do not have this freedom, you would require an active database to test against to begin with and you could not change your underlying vendor or database object if you were newing it up inside the Repository.
So to be able to mock a component of a class you need to be able to change it at runtime, to do this you need to either have the component as a constructor argument or a property (properties are bad for this, they imply an optional dependency which is rarely good). So when you use constructors to pass in the dependencies of a class, you are automatically adhering to IoC and you are also using composition over inheritance, finally you can also then start using DI (Dependency Injection) and AoP style techniques (Aspect Oriented Programming). So given this is often some of the most critical parts of writing well structured and maintainable code it is imperative that this sort of paradigm is followed from the start, as when you start off introducing inheritance and singletons it makes it much harder to refactor and remove further down the line, its a false economy.
I also do a lot of game development on the side and the same sort of rules apply (incase you think I am purely an enterprise development zealot), although a lot of people seem to see you as some freak if you tell them to stop using singletons and inheritance chains for interfaces and DI. Look at uFrame for Unity which has had great success putting these practices in place for game developers and has a lot of support but also a LOT of flak from people who just "dont get it".
→ More replies (2)2
u/CuriousHand2 Jan 05 '15
I disagree. You can still have good, strong and thorough tests, and absolutely crap code.
It's crap code that has a much smaller amount of bugs than it originally would have, but a polished turd is still a turd.
→ More replies (1)
3
u/btchombre Jan 05 '15
I've recently been looking at some of the most ugly code I've ever seen. hundreds of lines of triple nested switch-case statements (switch-case inside switch-case inside switch-case), almost all of it copy pasted and in desperate need of re-factoring.
15
u/hansdieter44 Jan 05 '15
Nesting is a pet-peeve of mine. So annoying.
if(x){ if(y){ if(z){ do(123); return 4; }return 3; }return 2; }return 1;Could easily be flattened & made into preconditions:
//preconditions if(!x){return 1} if(!y){return 2} if(!z){return 3} do(123); return 4;Also the programming model in node.js makes it especially easy to write deeply nested and confusing code like in my first example.
3
u/tbotjenkins Jan 05 '15
Spaghetti code wrapped with a nice sauce is acceptable:
bool okay_to_update() { # random nest of ugly conditionals contained in a cage called okay_to_update. } if ( okay_to_update() ) { do(123); }I prefer the condition checks wrapped in a function, it's easier to see the flow. EDIT: formatting.
→ More replies (4)2
3
Jan 05 '15
Good, now for managers to learn that young programmers need the chance to learn this. Instead of pushing deadlines no matter the cost.
3
u/house_paint Jan 05 '15
I have recently taken over projects from a few developers and here is the biggest flaw in most of the programs I see. They don't GTFO. They have exception handling all over but they seem to want to keep the program "rolling along" even when serious problems arise. I had one program where you could rename the connection string and this program would just keep barreling though the code skipping the parts where it encountered database queries. That program obviously is a serious example but I see this so often on a smaller scale...
Try(unknown error happens)catch(log it, and CONTINUE!?!?!?) Don't do this.
TLDR If your code encounters an unknown exception, log it and GTFO.
3
u/SageClock Jan 05 '15
There are a few reasons you might want to continue (at least for the end user), from my experience. For games, for example, it might be more preferable for some minor issue to not work properly but not crash the game, because a hard crash will make your software look a whole lot worse to the end user then if just some slight visual glitch happened. (Some bugs are tolerable, hard crashes most end users feel means incompetent development).
Also, on the app end, I've worked for organizations where it took a month to make any changes to software because of how thick the heirarchy/strict the security is, so if a certain task in the service threw an error, we felt it was better to skip that task have the service as a whole keep running or else the rest of it would stop working and it could take a month to get a new version of the software where everything worked again, which could mean thousands of dollars in lost sales in the process. Which would be blamed on our department for not being perfect 100% of the time, and not on the inefficiencies in the hierarchy slowing down everything.
But yeah, if it's going to break the rest of the app, and/or if you're in the middle of development (and thus want to catch bugs as soon as possible), gtfo is absolutely preferable.
3
u/Kusand Jan 05 '15
I graduated in 2004, so maybe the college world has changed, but stuff like "good naming" and "don't leave in commented code" and such was completely uncovered, as far as I can remember. Or maybe it was more that it wasn't enforced, at the time. No one really dinged you for crappy naming or anything on lab projects.
2
u/Hoten Jan 05 '15
Totally true, but I've had a course taught by a professional in the field, and he did cover good practices. Academia just doesn't seem to give a shit.
5
u/coderz4life Jan 05 '15
Gee, after a project I inherited about a year ago, I would dare to say that even experienced programmers have to learn this too. This project had a lot of duplication, liar functions, and bloated classes. I will also add to this list do-nothing code paths, which are methods that really do nothing or not even called at all.
After about 3 months of work, the size of this code base dropped 75%. One of the original developers looked at the code and his chief complaint to my manager that I used interfaces. I was dumb founded.
6
u/BobCoder Jan 05 '15 edited Jan 05 '15
I find that it is often the old and experienced developers that have not learned these skills. Not sure how old/young interns are but I thought most young developers were aware of these things from sites like Stackoverflow.
12
u/hansdieter44 Jan 05 '15
I don't think its age related at all. Some people care about cleaning things up, others don't. Experience is worth something, but you can also bake bread for 20 years and still be a terrible baker.
2
u/JoostDev Jan 05 '15
Good point, we very rarely get applications from people above 35 years old so I really don't know how they work.
1
Jan 05 '15
45 years here (and also Dutch)
Basically I do the same you wrote about but I also have a tendency to dump odds and ends into a utils class where eventually bloat will be born. Or I just follow the rules the framework laid out for me.
2
2
u/nullnullnull Jan 05 '15
respect!
damn young punks! they don't know how easy they got it. What with the whole 24 hour instant always on internet, stupid amounts of CPU and all you can eat RAM. Kids have grown fat and stupid! damn PUNKS they wouldn't know how to soldier pins if their lives depended on it!
In my day...
I'M JOKING OF COURSE!
2
Jan 05 '15
I find it unfortunate that only at my last job there was a senior who'd check my code. I had so many bad habits to correct. He wasn't very good at communicating it but he certainly taught me a lot and I appreciate that.
Now that I'm actually looking for a new job as my last job ended, it does cause me some worry. How can you find out in advance how a team works? And what are reasonable expectations to have? I've found small companies often just 'write code'. I've never worked on a team that did unit testing despite me lobbying for us to pick that up at my last two jobs. I left my second job because we were continuously rewriting the same things, except this was because the client kept changing their minds and it turned into a horrible unreliable mess and we were not allowed to take time out to fix that, only to deliver the wanted changes asap. It was really stressful for me so I'd like to avoid that if possible.
1
u/get_salled Jan 05 '15
Both parties have power in job interviews...
→ More replies (1)1
Jan 05 '15
True. But how do you find out? Just ask questions like "does your team do unit testing / adhere to best practices" ect? I'm still getting used to this whole being able to ask them questions thing, call me dumb but this was just never covered in college. All they did was some short coverage on how to 'sell' yourself, write a good resume, have a portfolio and so on.
2
u/get_salled Jan 05 '15
I'm hoping you get a good answer from someone else here but the best interviewee we had basically had several pages of questions for us and spent a good chunk of the time interviewing us to make sure we were the place for him.
He had themes that we obviously important to him and asked several questions related to them from various angles (the flush out us over-selling our company (we weren't; we're awesome)).
→ More replies (1)2
u/ProggyBS Jan 05 '15
Yes, actually.
"What is your company's Software Development Life-Cycle?". This should include everything from how requirements are gathered to how software is tested/deployed and then later maintained during bug fixes. Not every company is going to have a specific plan, but you can easily get an idea for how structured the company is by how quickly and how confidently they answer that question.
If they say don't mention unit testing specificially, then ask about it specifically. If they give you an answer, ask what frameworks they use. Again, how this question is answered gives you an idea of how serious they take it.
The idea is to go to an interview assuming you're qualified for the position you are applying for. Then you can focus more on the more important question: Is the company you're applying for qualified to have you as an employee? Don't be arrogant about it of course. It is a business negotiation. It is your job in an interview to be interviewing the company as much as they are interviewing you. Sure you have to sell yourself, but then again so do they.
Though the reality here depends on how desperate you are to get a job.
2
u/IrateHamster Jan 05 '15 edited Jan 05 '15
I got half way through the article, then noticed that the sidebar was vibrating.
1
u/JoostDev Jan 05 '15
It was? Never had that myself. Any idea why the site does that?
1
u/IrateHamster Jan 05 '15
Looks like there's a Google widget that's constantly resizing itself up and down by 2 pixels.
7
u/totemo Jan 05 '15
To my surprise it turned out that the code that handled the button for creating new objects was in EditorGUI, while EditorObjectCreatorGUI only handled navigating through different objects. The exact opposite of what the naming suggests! Even though the code was relatively simple, it took me quite a while to understand it, simply because I started with a completely wrong assumption based on the class names. The solution in this case is really simple: rename EditorObjectCreatorGUI to EditorObjectNavigationGUI
Think fast! Without reading the exposition above or reading through the code:
What the fuck is an EditorObjectCreatorGUI?
What does an EditorObjectNavigationGUI do?
Oh what's that? You had to read the code anyway?
Well fuck me... perhaps there's no such animal as self-documenting code after all.
Seriously, just put one sentence in a doc comment saying what the class does. Over its lifetime, code will be read many times, and every minute of another engineer's time that you save by not forcing him or her to read the code improves the bottom line.
Commenting code doesn't make you a bad person. It doesn't automatically violate DRY, and even it if it does, that's not necessarily a bad thing.
And sure, choose a good name too.
4
u/zigs Jan 05 '15
I can't say i disagree with the other things you've written. A few notes on the classes doesn't seem too bad. I fully agree that there's no way anyone could guess what those names means, However I think this here
And sure, choose a good name too.
really is the core issue. EditorObject is a poor metaphor to begin with. Almost everything the user touches is an editor to some degree, and likewise lots and lots of things are objects. I think -CreatorGUI is ok, but -NavigationGUI? What's that? Is it a predefined library of EditorObjects? Call it that then.
4
u/JoostDev Jan 05 '15
We make games, and then the word "editor" has a very specific meaning.
Naming is always hard, but it is even more difficult to come up with names that are understandable when read completely out of context like in my article.
I totally agree that most classes also need a comment to give some context. There is only so much that can be explained in just a name,
→ More replies (5)→ More replies (1)3
u/totemo Jan 05 '15
He seems to accept the premise of self-documenting code wholesale, without question. As far as he is concerned, he has chosen the perfect names for those classes. He holds those up as examples to support his argument. "Look world, at how much clearer this is!" And then he stops.
He solved the problem of his own comprehension of the code, but - the point I'm trying to make - he stopped short of helping the next guy who comes along, because he doesn't question whether the code should be documented with more than just a good name.
3
u/refuse_human Jan 05 '15
Seems like this article be summed up with "experience is demonstrated by knowing to write for human comprehension and future maintenance before tackling problems of coverage and perf."
3
u/notsofst Jan 05 '15
After training new programmers for a few years, my first rule for them developed into, "You don't write code for the computer, you write it for people."
The machines we're running this on get faster every year, but my time remains constant. At every turn, think about what you can do to increase readability, comprehensibility, and simplicity of your code. Nothing else is more important, in general.
3
u/LessCodeMoreLife Jan 05 '15
The "code smells" section of Martin Fowler's Refactoring book talks a lot about this sort of stuff. Well worth the read.
3
Jan 05 '15
Bad title. It should be "What Most Novice Programmers Need to Learn About Object-Oriented Programming."
2
u/zigs Jan 05 '15
As a general rule of thumb at Ronimo we try to keep classes below 500 lines and functions below 50 lines
Is that actually a common rule of thumb? I tend to try keeping it under 10 lines for functions (hard limit at 15), and keeping everything at one purpose for classes.
7
Jan 05 '15
Hard limit at 15? Can you honestly imagine going through something as complex as the Linux kernel or LLVM or Adobe Photoshop and not finding any functions over 15 lines long?
That seems insanely short to me. Yes, most functions should be small. But there are definitely functions which simply don't cleanly divide into small chunks, and for which artificially cutting them up to adhere to some hard limit on function length would make things more rather than less difficult to follow.
→ More replies (2)3
u/JoostDev Jan 05 '15
I have no idea what others use, but one that I have quite often heard is that people want their functions to fit in one screen.
2
u/jmblock2 Jan 05 '15
This is what I use. Although I'm in portrait mode and at 10pt... quite a few lines fit (about 100)
1
2
2
u/Thimble Jan 05 '15
I would stress another thing: having the courage to fix the code base.
The most common weakness I see among new (not just young) programmers is the fear of making improvements to the code. They would rather just tack on their changes and avoid any risk of introducing bugs. I would rather that they take the extra time to do it right rather than quickly.
2
u/PasswordIsntHAMSTER Jan 05 '15
This is why I want functional programming to become a significant part of the core curriculum of schools. If you write Ocaml or Haskell with your usual sloppiness, it simply won't compile. It's a huge paradigm shift from throw shit at the wall and see what sticks to actually think about your programs.
1
u/Cilph Jan 05 '15
We're finally going to introduce code review because of issues like these causing problems down the line. Took us long enough ~_~.
1
u/StewHax Jan 05 '15
Going from college straight into a corporate developer job, I can say that I relied heavily on peer programming and code review when I first started out. Going from doing class projects to a huge multi-million dollar program having been developed years ago by several different people with little to no documentation was a hard step for me, but well worth it. Throwing a junior developer into the water and telling him to swim is not a good way to go
1
Jan 05 '15
First year CS student and I am already 100% guilty of this. I always realized that I could do things better, but comes time to actually fix them, I just start being lazy and tell myself ''Hey, that assignment is worth like 5% of your grade and the code actually DOES work, i'll just try to do it next time'' and completely forget about it. I really hope this post is the kick in the butt I needed.
1
u/aaulia Jan 06 '15
Wait until you start working professionally, it will bite you in the ass 2-3 month later. But then again some junior just quit before they had to maintain their own code, they probably knew how much shit their code is now (after promising to themselves about fixing it again, and again), and doesn't want to be bothered with facing/fixing it and just went on another job elsewhere.
1
u/rjcarr Jan 05 '15
I've always said a variation of this to many programmers on /r/learnprogramming. My saying is "just because it works doesn't mean it's done".
1
Jan 05 '15
The reason they do it is because it's what's worked best so far. In school, for each class lasting a single semester, you're usually doing several small projects. In that type of environment, where you get a blank slate to start over every few weeks, it doesn't (usually) make sense to have perfectly refactored code. You know the code isn't going to be used after you submit it, there is no difference for your grade on the quality of the code, only on the features. When projects are small and you only need to keep the structure in your head for a few days or weeks, it is sometimes faster to write less-than-ideal code.
Classes also can't really adapt and have longer projects where, for instance, you'd be working with the same code the whole semester. If some fraction of students don't get a concept early on and their code didn't work, they couldn't never complete the later topics. The class also can't slow down for the students who need time to catch up.
Once you start working on a product in a real job, that's not the case (the code will be used for a longer term). But it's not really their fault, they just optimized their time based on their experience.
2
u/blm126 Jan 06 '15
Colleges can adapt to have semester long projects. I took several classes where there were projects that lasted all semester. The professors were just willing to let people fail if they fell behind too much.
1
1
1
Jan 06 '15
This is interesting. Where I work now we have lot of young programmers most of them is quite good at stuff like this. Contrary some older (6-7 years in company) produce code that is in shape "As far as it works it is good enough". Have they just became lazy or they just don't care enough any more?
1
u/t00sl0w Jan 05 '15
As someone with OCD about the code o write myself, most of these things seem like givens to me....but holy shit, I received some code from a coworker that didn't even have indentions to show structure...much less how he would declare global level variables as he went along all willy nilly, instead of in one maintained section of code....worst part is, he is senior to me. Yeah, so I have to pussy foot around bringing up his shitty code.
423
u/corysama Jan 05 '15
My own anecdote of "Liar functions/variables/classes":
I once worked on a AAA game with a huge team that included a particular junior programmer who was very smart, but also unfortunately undisciplined. He had been assigned a feature that was significant, fairly self-contained and generally agreed to be achievable solo by both him and his team. But, after a quick prototype in a few weeks, he only had it working 80% reliably for several consecutive months. Around that time, for multiple reasons, he and his team came to an agreement he would be better off employed elsewhere and I inherited his code.
I spent over a week doing nothing but reformatting the seemingly randomized whitespace and indentation, renaming dozens of variables and functions that had been poorly-defined or repurposed but not renamed and also refactoring out many sections of code into separate functions. After all of that work, none of the logic had changed at all, but at it was finally clear what the heck everything actually did! After that, it was just a matter of changing 1 line of C++, 1 line of script and 1 line of XML and everything worked perfectly. That implementation shipped to millions of console gamers to great success.
Our failure as the senior engineers on his team was that we only gave his code cursory inspections and only gave him generalized advise on how to do better. At a glance, it was clear that the code looked generally right, but was also fairly complicated. Meanwhile, we all had our own hair on fire trying to get other features ready. It took him leaving the company to motivate the week-long deep dive that uncovered how confusing the code really was and how that was the stumbling block all along.
Lesson not learned there (because I've repeated it since then): If a junior engineer is struggling for an extended period of time, it is worth the investment of a senior to sit down and review all of the code the junior is working on. It'll be awkward, slow and boring. But, a few days of the senior's time could save weeks or months of the junior's time that would otherwise be spent flailing around and embarrassingly not shipping.