11–20 of 29 posts
Point being that most people probably don't get the most out of, say, Python's standard library.
However, in a professional environment you would expect that the lead developer(s) had already given this stuff a lot of serious thought and enshrined it in a coding standards document for every member of the team to follow.
As a novice programmer, I found this article to be a good bump towards thinking for myself. Too often I find myself doing something because its what the tutorial or book I was reading said was best practice, without really thinking the situation through. Being able to explain why you are making the decisions that you make seems like an important step between just haphazardly piecing together snippets of code you memo…
These 12 points seem to be the most insignificant things you can think about your code. Indentation? Camel case? Come on... mastering WRITING code will not make you a good coder. It will make your code consistent, I'll concede, but there's nothing stopping your from writing consistently bad code that looks good. Wouldn't it be more fruitful to think things like: 1) Why did I write this code as one function? 2) Should…
I understand the point of the exercise and I can see that an individual coder might gain some benefit from this. However, in a professional environment you would expect that the lead developer(s) had already given this stuff a lot of serious thought and enshrined it in a coding standards document for every member of the team to follow.
[1] Or do it at merge time if your setup involves pushing to a "work" repo which is merged to the real codebase later.
These 12 points seem to be the most insignificant things you can think about your code. Indentation? Camel case? Come on... mastering WRITING code will not make you a good coder. It will make your code consistent, I'll concede, but there's nothing stopping your from writing consistently bad code that looks good. Wouldn't it be more fruitful to think things like: 1) Why did I write this code as one function? 2) Should…
The two go hand-in-hand. Writing articulate easy-to-read code does not mean it precludes thinking about the things you mention. You could be the best (according to your criteria) coder in the world, but if your code is unreadable, it will quite literally waste others' time. This might not seem like a big deal with a smaller project, but scale to something the size of the Linux kernel or larger and it begins to become…
Have you actually experienced a coder that writes good code but writes it in a manner that prevents you from understanding it? I'd love to see some actual code samples.
These 12 points seem to be the most insignificant things you can think about your code. Indentation? Camel case? Come on... mastering WRITING code will not make you a good coder. It will make your code consistent, I'll concede, but there's nothing stopping your from writing consistently bad code that looks good. Wouldn't it be more fruitful to think things like: 1) Why did I write this code as one function? 2) Should…
But the exercise shouldn't stop there, as your program develops questions like yours should be asked and understood and defined. The more questions you can ask yourself, the better you'll understand your thought process.
New developers might not get far past my list. Most devs might ask some but not all of your questions. The best developers will realize more fundamental questions to ask about their decisions. Hopefully everyone can learn something new by asking those questions.
I understand the point of the exercise and I can see that an individual coder might gain some benefit from this. However, in a professional environment you would expect that the lead developer(s) had already given this stuff a lot of serious thought and enshrined it in a coding standards document for every member of the team to follow.
Now, you're right, the easiest questions (as in the article) to answer can and should be encoded in standards document. But there are many many questions to ask and some are highly dependent on context and don't belong in standards documents. Maybe some of the existing standards that you thought you understood are really just there by convention and could be improved.