5 ms·

I've been called a perfectionist because of my coding maintenance. Dozens of my commits are "Source code formatting", where I try to make the code closer to PEP

by inerte 16y ago

I've been called a perfectionist because of my coding maintenance. Dozens of my commits are "Source code formatting", where I try to make the code closer to PEP8 (Python). But I don't go actively looking for things to "fix". While reading code, if only one line is separating functions, I add another. I add \ to line ends trying to limit width to 80 chars. Lately my mantra has been "Shipping is a feature". Code working is my number one priority. But like most of the people, I like to think I'm above average, so I don't believe I write _bad_ code at the first time. I know it's not perfect. Just by saying this, I remember of things I know I should change to make the code better, but why bother? What you must always pay attention is the balance between creating value for your customer, and for you as a professional. And even when you do things for yourself, always remember your main objective is to make things easier in the future to create value for your customers. Caveats apply, of course. A refactoring to allow more modularity or whatever in the future might be good to do now, but honestly usually there are more pressing matters (unless the current pressure is to add some module functionality). It's hard to give any straight answer. There are no hard rules, like "you should only refactor during one hour per-day". Maybe you're doing something where a big-design-upfront is not possible. Maybe not. These things come with experience, tough. And where you want to keep your focus. If I was working on a 10 year code base where the original programmer has left the company, and didn't document anything, then I guess I would spend more time nurturing the code. But my job today is too fast paced, and "when it will be ready" is my customers/stakeholders number one priority. I negotiated and told them quality would suffer, and they are aware, but don't care much.

mishmash 16y ago
> What you must always pay attention is the balance between creating value for your customer, and for you as a professional. Great point. By not having customers right now, I've likely started to overvalue my own development/investment.
jay_kyburz 16y ago
Do you really find python easier to read when lines are broken with a slash at 80 chars. I don't bother until twice that.
- farzadb82 16y ago
  I'm not so sure about 160 chars, but I do agree that 80 chars is a little ridiculous these days. I have not yet one good argument for 80 chars. Most terminals and monitors today will easily go to 100 chars, which is typically where I prefer to break lines. This gives room for 3-4 levels of nesting (using 4 char tabs), which is about the max depth you'd want to nest. There are exceptions of course but for the most part any more than 3-4 levels deep and you should be looking at refactoring.
- inerte 16y ago
  Not really. I was doing "whatever fits on my 22 widescreen monitor", but a teammate asked me to keep on 80, and I started to change my style to make him happy. Then a new member came to the team, and his coding style was not very good. I told him to read and follow PEP8, he downloaded some script which checks source for PEP8 compliance, and he really made the effort to format his code. So, it's not something that I would personally go insane trying to keep width to 80, but when two things happened: I was already doing most of the PEP and my teammate wanted me to keep 80 chars, and I had to eat my own dogfood :) when the new person came on board. In the end, it's something easy to do, and keep my colleagues happy.
fexl 16y ago
I stay happy as long as my black box continues to function as advertised. That keeps me from obsessing over internal details. Ugly code can stay ugly and I sleep fine at night. But whenever I wade into the code for good reason, I reward myself by refactoring whatever areas I happen to touch. It's like throwing a fish to a seal. That way I always get a chance to do fun things like unifying similar code or making code more data-driven. I'm still a perfectionist, but I'm also a strategic procrastinator. So while I'm working on code, whenever I think of anything, however small, that might improve it, I'll throw in a comment such as "TODO 0703 might want to tighten this up" or "TODO 0703 you need to test this case before releasing". I am so relentless and unforgiving that sometimes the TODOs multiply like rabbits. Before I release anything, I grep on "TODO". As long as any TODOs show up, I can't release. If I need to put off something until later, I'll change that "TODO" to "LATER". Occasionally I'll make a point of revisiting my LATER entries, converting some of them back to TODO. That way perfection is an ongoing process, not an attained state.
- Quiark 16y ago
  The problem I have with refactoring todos is that after a time it's no longer clear to me why the refactoring was needed (unless it's obvious, but in that case I probably already did it).
  - fexl 16y ago
    To be clear, I usually add TODOs only for observable features and enhancements, rarely for internal issues like refactoring. My point is that I usually refactor only when I'm already in the code for other reasons, as a reward for doing the immediate observable changes. This helps focus my refactoring efforts only on code that is already changing for the customer's benefit.
- HeyLaughingBoy 16y ago
  We actually did this on one of our releases. There was a task to scan the entire code base and either fix all TODOs or write a justification for why it could safely be ignored. Amazing what you can find when that happens :-)

by inerte 16y ago

mishmash 16y ago

> What you must always pay attention is the balance between creating value for your customer, and for you as a professional. Great point. By not having customers right now, I've likely started to overvalue my own development/investment.

jay_kyburz 16y ago

Do you really find python easier to read when lines are broken with a slash at 80 chars. I don't bother until twice that.

farzadb82 16y ago
I'm not so sure about 160 chars, but I do agree that 80 chars is a little ridiculous these days. I have not yet one good argument for 80 chars. Most terminals and monitors today will easily go to 100 chars, which is typically where I prefer to break lines. This gives room for 3-4 levels of nesting (using 4 char tabs), which is about the max depth you'd want to nest. There are exceptions of course but for the most part any more than 3-4 levels deep and you should be looking at refactoring.
inerte 16y ago
Not really. I was doing "whatever fits on my 22 widescreen monitor", but a teammate asked me to keep on 80, and I started to change my style to make him happy. Then a new member came to the team, and his coding style was not very good. I told him to read and follow PEP8, he downloaded some script which checks source for PEP8 compliance, and he really made the effort to format his code. So, it's not something that I would personally go insane trying to keep width to 80, but when two things happened: I was already doing most of the PEP and my teammate wanted me to keep 80 chars, and I had to eat my own dogfood :) when the new person came on board. In the end, it's something easy to do, and keep my colleagues happy.

fexl 16y ago

I stay happy as long as my black box continues to function as advertised. That keeps me from obsessing over internal details. Ugly code can stay ugly and I sleep fine at night. But whenever I wade into the code for good reason, I reward myself by refactoring whatever areas I happen to touch. It's like throwing a fish to a seal. That way I always get a chance to do fun things like unifying similar code or making code more data-driven. I'm still a perfectionist, but I'm also a strategic procrastinator. So while I'm working on code, whenever I think of anything, however small, that might improve it, I'll throw in a comment such as "TODO 0703 might want to tighten this up" or "TODO 0703 you need to test this case before releasing". I am so relentless and unforgiving that sometimes the TODOs multiply like rabbits. Before I release anything, I grep on "TODO". As long as any TODOs show up, I can't release. If I need to put off something until later, I'll change that "TODO" to "LATER". Occasionally I'll make a point of revisiting my LATER entries, converting some of them back to TODO. That way perfection is an ongoing process, not an attained state.

Quiark 16y ago
The problem I have with refactoring todos is that after a time it's no longer clear to me why the refactoring was needed (unless it's obvious, but in that case I probably already did it).
- fexl 16y ago
  To be clear, I usually add TODOs only for observable features and enhancements, rarely for internal issues like refactoring. My point is that I usually refactor only when I'm already in the code for other reasons, as a reward for doing the immediate observable changes. This helps focus my refactoring efforts only on code that is already changing for the customer's benefit.
HeyLaughingBoy 16y ago
We actually did this on one of our releases. There was a task to scan the entire code base and either fix all TODOs or write a justification for why it could safely be ignored. Amazing what you can find when that happens :-)