I know I have this. Why me!? I hate it... Sometimes I feel like I can't get anything done. Like it takes hours to do the simplest task I've done before. I'm always changing code to make it look pretty or other things. It's too much! Please someone tell me I'm not the only one going through this here? I've read that I have to face the fear and not allow my self, or ignore the OCD. I don't know man...
So I've been working on this game for a while and I keep getting stuck on basic architecture. I keep re-writing or changing the image & sound loaders. Constantly loading up thesaurus.com looking for a different word that would align with other variable names... see what I mean? It's bad. I know its most important to deliver a working product, NOT what the source code OF the working product looks like. I've seen lots of professional products and it seams that these guys don't suffer like I do.
There is a catch though. If I re-factor to much then, the OCD part of me, gets all pushed out of shape because to code looks to clean or to procedural if you know what I mean. So it seams that OCD has double standards... or maybe double edged. Either way its holding me back and I'm not able to complete what I want to do. Anyone else feel my pain? I just don't know what to do with my self...
Obsessive Compulsive/Refactoring Disorder
I'd like to believe it's a stage, but I do the same thing. I've never seen it as a problem though. I value clean organized code and it bothers me when code I work on is not formatted correctly. I've gone through tens of thousands of lines of code and formatted them all to a strict style in the past when I had time. It's important to realize that everyone else is wrong and that you are right when it comes to these changes. 
Naming problems are common problems. It gets easier to name methods and classes with experience.
Also refactoring code to make it better is a good practice. As said a thousand times evolution, not revolution.
As a tip I recommend coding with whitespace hidden characters on. It helps to relieve the anxiety of not knowing.
Naming problems are common problems. It gets easier to name methods and classes with experience.
Also refactoring code to make it better is a good practice. As said a thousand times evolution, not revolution.
As a tip I recommend coding with whitespace hidden characters on. It helps to relieve the anxiety of not knowing.
I know I have this. Why me!? I hate it... Sometimes I feel like I can't get anything done. Like it takes hours to do the simplest task I've done before. I'm always changing code to make it look pretty or other things. It's too much! Please someone tell me I'm not the only one going through this here? I've read that I have to face the fear and not allow my self, or ignore the OCD. I don't know man...
I think it's just you.
So I've been working on this game for a while and I keep getting stuck on basic architecture. I keep re-writing or changing the image & sound loaders. Constantly loading up thesaurus.com looking for a different word that would align with other variable names... see what I mean? It's bad. I know its most important to deliver a working product, NOT what the source code OF the working product looks like. I've seen lots of professional products and it seams that these guys don't suffer like I do.[/quote]
Well, if you rewrite modules and make them faster or better, there's nothing wrong with it...If you are just changing variable names, then you've got issues.
There is a catch though. If I re-factor to much then, the OCD part of me, gets all pushed out of shape because to code looks to clean or to procedural if you know what I mean. So it seams that OCD has double standards... or maybe double edged. Either way its holding me back and I'm not able to complete what I want to do. Anyone else feel my pain? I just don't know what to do with my self...
[/quote]
Yes and no, but does your IDE has a code formatting tools? Don't use freaking notepad or vim or gedit just because they are fast. So many times I have looked at source code that others have written, and so many times I have seen them improperly formatted. This shit would bug me as hell:
if (someFlag)
doSomething();
if( someOtherFlag ) {
do_something_else();
}
Select All -> Reformat Code. Then refactor do_something_else() to doSomethingElse(). Done.
I've had this for ages. Something I've started experimenting with recently is schedules. Turns out the same thing that the games industry is so often decried for: unreasonable deadlines and milestones -- are a good way to cajole oneself into coding up a storm with little regard for good architecture. Of course, this way potentially lies unmaintainable spaghetti. A solution for that is obvious: Schedule time specifically for refactoring too. Not so much that you spend all your time in refactoring hell, not so little that you spend more time trying to understand your code than add to it.
I've been doing 3 hour "jaunts" for personal projects off and on, with 30 minute scheduling intervals. Of course, I could spend forever comming up with an ideal schedule: So I schedule myself 10 minutes to come up with a schedule. I coded up a small program to help me keep track of exactly how far behind I'm getting, even.
It seems to work best when I have a clear idea of what I want done. This includes refactoring too: for me, I can't just add a 30 minutes task, "Herp derp refactoring", and hope to get something good done. On the other hand, when I've got a pile of spaghetti in mind, and I know I want to split it up into 4 classes along obvious lines -- sure, I'll throw 30 minutes for "refactoring" onto the list. If I overbudgeted for that specific change, great -- start the next task early. If I underbudgeted, that's another class or two worth of behavior I can refactor out of my mess tomorrow.
Consider trying it
I've been doing 3 hour "jaunts" for personal projects off and on, with 30 minute scheduling intervals. Of course, I could spend forever comming up with an ideal schedule: So I schedule myself 10 minutes to come up with a schedule. I coded up a small program to help me keep track of exactly how far behind I'm getting, even.
It seems to work best when I have a clear idea of what I want done. This includes refactoring too: for me, I can't just add a 30 minutes task, "Herp derp refactoring", and hope to get something good done. On the other hand, when I've got a pile of spaghetti in mind, and I know I want to split it up into 4 classes along obvious lines -- sure, I'll throw 30 minutes for "refactoring" onto the list. If I overbudgeted for that specific change, great -- start the next task early. If I underbudgeted, that's another class or two worth of behavior I can refactor out of my mess tomorrow.
Consider trying it
Frigging whitespaces at the ends of lines. Running a macro on them every 5 seconds is slow and looking at them when a block of text is selected burns the eyes even more. Horrible. Just horrbile.
What I've found most useful is 50/50 as a guide: Do not spend more time refactoring than developing new functionality.
Sure, one could spend hours, or days, or weeks improving the functionality, here and there, just a little... But you do need to get something done and deliver it.
If it's taking significantly longer to refactor than to write real functionality, then something is really wrong. Even if it's really bad code that someone else wrote, then it's time to recognize that some of the correction and repair of their bad work will have to be put off until later. If it's one's own work, then maybe a little more discipline while doing the work is in order. ;->
Sure, one could spend hours, or days, or weeks improving the functionality, here and there, just a little... But you do need to get something done and deliver it.
If it's taking significantly longer to refactor than to write real functionality, then something is really wrong. Even if it's really bad code that someone else wrote, then it's time to recognize that some of the correction and repair of their bad work will have to be put off until later. If it's one's own work, then maybe a little more discipline while doing the work is in order. ;->
And here I thought I was just about the only person who still cared about spaces at the ends of lines! ;->
I knock them off when I happen to be working on those lines for other reasons. And any good editor that can handle regular expressions can kill them easily enough. And formatting tools can do it for you too.
Still, it puzzles me as to how and why people keep adding spaces to the ends of lines -- seemingly by habit, at times. Some behavior is just odd.
What I've found most helpful is to get the team to agree to an automatic formatter, and then apply it consistently -- preferably automatically at check-in. Yes, I dislike automated formatters too. But I've found the inability of some programmers to keep with anything like a consistent style, even all the way through a single line of code, to be quite annoying. Code is read much more than written. It has to be readable.
I knock them off when I happen to be working on those lines for other reasons. And any good editor that can handle regular expressions can kill them easily enough. And formatting tools can do it for you too.
Still, it puzzles me as to how and why people keep adding spaces to the ends of lines -- seemingly by habit, at times. Some behavior is just odd.
What I've found most helpful is to get the team to agree to an automatic formatter, and then apply it consistently -- preferably automatically at check-in. Yes, I dislike automated formatters too. But I've found the inability of some programmers to keep with anything like a consistent style, even all the way through a single line of code, to be quite annoying. Code is read much more than written. It has to be readable.
There are a lot of things that annoy me: Unimaginative or slightly inconsistent variable/function names, or perhaps the organisation of code blocks are somewhat weird compared to the rest of the project. In my world, these problems tend to appear when I work on something for a long time, or perhaps I revisit a project that was shelved a while back. I noticed my coding style can change over time, which is probably the primary reason why I have these issues. But these a minor issues. I have to discipline myself not to polish too much, and rather focus on getting things done. Therefore, I tend to refactor things when adding a new feature to a section of code. More importantly, I limit refactoring to that part of the code only. I mean, new features need a fair bit of work anyway, so might as well improve the stuff around it at the same time.... with care.
Still, it puzzles me as to how and why people keep adding spaces to the ends of lines -- seemingly by habit, at times. Some behavior is just odd.[/quote]
Virtual spaces. It usually happens to me when I comment code, then for whatever reason I remove them later, but forget to cull the whitespace before the comment. Another reason, leftovers from indentation.
I'm actually surprised most code editors don't have a feature that strips whitespaces for you (at least in VS i cant find it). I remember Borland Pascal and C had it a while back.
At work I apply a simple rule: I do not allow myself to cleanup or refactor code unless I have something that needs to be done in the file. So if I'm not fixing a bug or adding a feature, then I leave well enough alone. I don't quite have the disciple to force myself to do this with my own code, but I'm trying.
MaulingMonkey's points are good. If you don't have a schedule, or a bug tracker to prioritise work, then you end up wasting time doing this kind of thing. Refactoring feels like work, but rarely gets the project closer to release. Refactoring is supposed to be a time saver, making the code easier to read, debug, maintain and extend. If you aren't saving time doing it (in the long run), then something is wrong.
MaulingMonkey's points are good. If you don't have a schedule, or a bug tracker to prioritise work, then you end up wasting time doing this kind of thing. Refactoring feels like work, but rarely gets the project closer to release. Refactoring is supposed to be a time saver, making the code easier to read, debug, maintain and extend. If you aren't saving time doing it (in the long run), then something is wrong.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
