31–40 of 108 posts
Well-organised code with sensible, correct naming of things will save you years of development time during your career.
One tip I'd offer is: You are not inventing something by naming it, you are describing how it's used (based on its behavior).
If it's hard to name, one possibility is that it is not designed properly or that it's doing too much.
I think I started reading after @edw519 said something like he reads his code everyday before going to sleep. While during writing my focus is on making the thing work when I am reading I am more critical of my code. Not as good as having a review but still helpful.
Also I think reading code of other programmers is a good exercise. Reading different styles of books is already recommended to writers and I think that programmers can extract same benefit by reading code of different programmers. If nothing else at least it will develop your debugging abilities.
Earlier quoted context omitted.
Everyone hates to do it, but a lot of this comes from reading code. The more code you read, the more you'll learn to understand idioms, styles, what makes things good and bad for understandability. Then you'll be able to do it yourself. Another point to make: while every language has it's own idiom and style, there are also lots of "clean code" lessons that apply across languages, so guides about, e.g. python, transl…
It depends on what code you read, though. Think of PHP devs that learn from WordPress, for instance. It's not exactly setting a great example... (Though to their credit, WordPress improved somewhat in recent years.)
If I had only read Dickens, I might think writing a novel entailed finding only strange characters, pointing out social flaws. Keeping a thematic style that was about confusing light and dark with the normal associations. And so on.
If I had only read Twilight, I wouldn't care much about dialog or character development. I wouldn't understand that there are things you can do thematically without exposition.
If however read Dickens, and Hemingway, and Tolkein and Dan Brown, and Stephanie Meyer and ... I would have a different understanding of what could go into a novel. I would be able to see where story arc intersects with bigger themes and character development. I would see different ways of structuring sentences, paragraphs, chapters, and even whole books.
None of this reading of course will make me a great author, writing does that, but a wide exposure will certainly help me understand where my writing is working vs where it isn't, it will help me understand how to structure things, help me shape my own work.
I consider the same to be true of code. The folks that only read WordPress code have a very limited understanding of possibilities. The folks who have read that, and rails and django, and jekyll and flask and ... will see a wide range of styles, ideas about structure, and so on.
An aside: Wordpress has some pretty ugly parts, but there are some ideas in there about structure that I have always liked. Particularly considering it was designed and written during the "explore and figure out what works" phase of web apps, when the industry didn't really have a "best practices for the web" that included lots of experience with what does and doesn't work.
I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…
The short answer is "yes, it's worth the time". One big improvement I've made in my code over the years is that I take the time to improve my code. Continuously improving code quality does lead to high code quality, and high code quality reduces maintenance hours (both amount needed and time spent).
If you're writing the code which will live at least a month — definitely. But if you're writing a quick hack of a project or test that you're know won't be around next week, it's often a real waste of time and effort.
And I'm not writing about that theoretically now: for me personally, it's a real problem. Whenever I sit to write a simple dirty hackey thing, I always find myself a few hours later googling for the best way to implement unit tests for this particular case or something like that. Which is sometimes educational, but is very distracting.
I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…
Why do you ask for a permission? If I am working on a task and code got a bit too messy for my liking, I'd simply refactor, it's simply part of the task. Working != complete. If something goes wrong, it will be easy to revert given it is committed in a sane way (i.e. not loads of unrelated work under one commit). It's a bit different if you want to do major refactoring (taking multiple days). But with small ones, jus…
I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…
1. Making the code cleaner is reducing technical debt. This will help in the long run, and I just sort of do it as I go. It's like tidying the house - it is more efficient to do little things regularly than to have a giant mess to deal with later. The little things make it easier to do something later, because you don't find yourself yak shaving as often to get to the main task.
2. In my personal and observed experience - doing the fixes at first seams like heavy task. "it works, this is just grunt work", but as you get practice at it, you'll find that it helps find bugs, it becomes a habit, and you just do it as you go.
3. It helps me understand the code better. Even if I wrote it. Just because I got it to pass tests doesn't mean I know why at first - but cleaning up the code makes me realize edge cases and what's happening.
One thing that helps is to keep in mind the axiom "all code sucks. Some code is useful" (to paraphrase a famous saying). I know when I code stuff, I tend to do a throwaway implementation or two first, just to wrap my head around the problem, then keep one. After a few months, I'll revisit and understand even better what to do, and rework it again. Then maybe it's decent.
I'm sure there are people out there who can do it great the first try, but they aren't that common. The secret is to not wrap your ego/identity as a programmer/understanding of accomplishment up in the code you've written, but in your ability to solve or lessen the problems that come up.
I'm just not sure you can teach these things to a junior programmer, and actually expect to see results. A baby takes 9 months to develop, you can't expect to see finger nails develop until they've developed fingers. As a junior, you're probably spending most of your time (and a lot of it at that) just trying to make the dang code work. Making sure it's written in a way that other people can maintain it etc is second…
But, from years of managing summer interns, the biggest surprise to new programmers is the amount of non-code stuff that needs to be done alongside actual coding. Doc, comments, peer reviews (and the associated rework). The sooner they learn this is part of the job, the sooner they'll fit into the team's workflow and contribute at a high level.
I'm just not sure you can teach these things to a junior programmer, and actually expect to see results. A baby takes 9 months to develop, you can't expect to see finger nails develop until they've developed fingers. As a junior, you're probably spending most of your time (and a lot of it at that) just trying to make the dang code work. Making sure it's written in a way that other people can maintain it etc is second…
Yes, new programmers spend a lot of time just getting things to work. But, from years of managing summer interns, the biggest surprise to new programmers is the amount of non-code stuff that needs to be done alongside actual coding. Doc, comments, peer reviews (and the associated rework). The sooner they learn this is part of the job, the sooner they'll fit into the team's workflow and contribute at a high level.