text: #1 Members - Reputation: 815
  Posted 22 September 2012 - 04:08 PM
  My first question is, do you guys often do the quick and dirty thing, and then go back to fix it later; or do you get a hold of yourself and make sure you get the job done well, first and foremost?
  My second question is, what is your attitude about refactoring? I've heard Code Complete is good, and I've been recommended Refactoring by Martin Fowler, but I won't have the money for those books for a little while, and I think my question is specific enough to ask and expect reasonable answers. To narrow it down: Do you refactor while coding, or do you refactor after everything's done? I've always thought it might be good to take breaks during long projects to fix up what's there already before moving on, but I dunno. Could you guys share a little on that? Thanks.
  #2 Crossbones+ - Reputation: 2096
  Posted 22 September 2012 - 05:16 PM
  1. How big a job or time-consuming of a job is the re-factoring going to be?
  2. Where are you in terms of deadlines and external commitments to getting stuff done.
  3. How bad is what you have without re-factoring and how bad is it going to be to continue with it without re-factoring.
  Generally, for hobbyist or personal projects you can do whatever you want but just be wary of the fact that constantly rewriting stuff in an attempt to make everything perfect and beautiful is a good way to never actually finish anything.
  For non-hobbyist / stuff you are doing professionally, it's a different situation -- often the choice isn't yours to make when dates need to be hit and so forth.
  Edited by jwezorek, 22 September 2012 - 05:16 PM.
  #3 Crossbones+ - Reputation: 1666
  Posted 22 September 2012 - 07:12 PM
  It's half a jest, but seriously, good design is not very hard, and provides enormous returns for your effort. Good design is all about making your life easier. If you're spending more time designing and coding something "elegant" versus only coding something crufty, you're not doing it right.
  #4 Members - Reputation: 756
  Posted 22 September 2012 - 08:51 PM
  I usually split coding to small tasks, after each task, I refactor for it.
  Or I will refactor if there is enough code, eg. 1000 lines of code.
  The small refactor is lower cost than big one (refactor after whole project is done). Crossbones+ - Reputation: 23779
  Posted 22 September 2012 - 09:32 PM
  I don't refactor for refactoring's sake, but only when the code is messy or will soon become messy through changes that refactoring could prevent.
  As Geometrian says, it's best to write it clean the first time. My code usually is clean the first time, and only accumulates cruft over time from additions - that's when I refactor. Occasionally (but not too commonly), I need to refactor after writing it the first time because I had difficulty comprehending the first time through. I'm talking function-level refactoring, not architecture-level refactoring. I have to do architectural refactoring every so often because I'm still learning good architecture and make alot of mistakes there.
  Code Complete is worth the money when you can get it.
  Edited by Servant of the Lord, 22 September 2012 - 09:36<<
  #6 Senior Staff - Reputation: 21816
  Posted 22 September 2012 - 10:42 PM
  This really depends on a number of factors:This really depends on a number of factors:
  My first question is, do you guys often do the quick and dirty thing, and then go back to fix it later; or do you get a hold of yourself and make sure you get the job done well, first and foremost?
  - Why are you writing the code?
  - Is this just a quick disposable test to find out if an idea works, or is it production code? If it's just a quick test that will be thrown away it's often best to simply get it working as quickly as possible, but production code should always be as clean as you're able to manage within any other constraints
  - Is the code part of a larger project and/or likely to be reused? Are you likely to need to adapt the code for other uses? When writing code that will be re-used, which you might need to re-purpose, or which will be part of a larger system it's important that you design it as well as possible. If you're writing a little script to automate a one-off task it really doesn't matter as long as it gets the job done properly.
  - Are you time limited? If you have a deadline to meet you might not have time to formulate and implement a better solution. Obviously if the "quick and dirty" solution is too dirty and will cause extensive additional problems or might not work correctly you'll need to try your best to get the deadline extended, but if it's going to work fine and won't cause a massive blow-out in some other area or at a later stage then it can sometimes be necessary to simply choose the solution that allows you to meet your deadline.
  - How "dirty" is the "quick and dirty" solution? As above, is it just a sub-optimal solution that will otherwise work alright, or are there serious problems with it?
  - Who will have to work with the code? If it will never be touched again it probably isn't overly important. If you're the only one who will have to work with it you might be comfortable with the less optimal solution for now. If others will have to work with your code then you probably want to put your best effort into the best/clearest design you are able to implement.
  A bit of both if needed, although refactoring while coding can normally be kept to a minimum -- almost entirely eliminated once you're more experienced -- by designing properly in the first place.A bit of both if needed, although refactoring while coding can normally be kept to a minimum -- almost entirely eliminated once you're more experienced -- by designing properly in the first place.
  Do you refactor while coding, or do you refactor after everything's done?
  Do the best you can, but expect to make mistakes as you learn and grow as a programmer. It won't always be practical to fix all your mistakes if you want to continue to progress, but as long as you recognise and learn from them that's fine -- save perfection for when you're writing important code.
  ...and just to re-enforce what others have said, Code Complete is well worth the money once you've saved up.
  - Jason Astle-Adams.
  From my blog: 20 ways to advertise your game | What next? Intermediate to advanced C++
  How to make games WITHOUT programming | 4 reasons you aren't a successful indie developer
  #7 Members - Reputation: 1573
  Posted 23 September 2012 - 03:39 AM
  Ideally, I'd like refactoring tools in IDEs to work with version control to check in and revert as I refactor/undo - and potentially even branch when I start refactoring then merge when I'm done and the tests pass.
  #8 Members - Reputation: 930
  Posted 23 September 2012 - 12:18 PM
  I mostly work in Java these days, so Eclipse's refactoring tools are often leveraged to re-organize my namespace, especially moving inner classes out into their own files with just two clicks. Moving classes from one namespace to another with all references kept intact is always nice.
  When I do have to arrive at a specific interface, though, which is about half the time at work, I naturally have to work the same way we arrived at that interface spec in the first place; start at the goal, and problem-solve my way to the implementation that achieves it. This is generally actually faster than the other way, but because I won't always have progressively implemented versions along the way to the final product, it usually feels slower.
  ((_12<<
  #9 Crossbones+ - Reputation: 1263
  Posted 23 September 2012 - 12:38 PM
  I'm a researcher myself so whilst I do work to external deadlines they are no of the frequency of, say, a professional programmer. The shelf life of my code (almost exclusively prototype applications) is very short so it's all to easy to write disposable "fire and forget" code as one is lulled into the false sense of security that such code is "one use only" and not worth exercising some discipline over. This lax attitude had cost me unnecessary (and precious) time on more than one occasion when an important deadline gets dumped on me at short notice.
  #10 Members - Reputation: 1199
  Posted 23 September 2012 - 07:35 PM
  Sometimes refactoring adds nothing to the codebase other than piece of mind. Other times it spawns useful ideas you might not have had otherwise.
  #11 Members - Reputation: 739
  Posted 24 September 2012 - 03:03 AM
  I found "Refactoring: Improving the Design of Exisiting Code" By Martin Fowler et. al. a good book about how and when to refactor. It not just covers some technical aspects but also a lot about increasing productivity and code-stability from refactoring.
  #12 Crossbones+ - Reputation: 3426
  Posted 24 September 2012 - 04:29 AM
  Sure, for some prototyping it can be motivated, but it should be cleaned up before commit to the trunk.
  For longer prototyping, a branch might be motivated.
  That doesn't have to mean you have to do a _refactor_ every time, if your design is sensible to begin with, it shouldn't be very hard to add functionality in a graceful manner, no matter what this functionality might be.
  Though, of course your design is never perfect, and sometimes needs a slight refactor.
  As others have pointed out, these should be done on a stable code base, so you can verify it works as it should both before and after.
  Edited by Olof Hedman, 24 September 2012 - 04:30 AM.
  #13 Crossbones+ - Reputation: 17640
  Posted 24 September 2012 - 05:22 AM
  Do it right the first time. If you can’t figure out exactly how it should be done, don’t do it. Keep planning. Writing algorithms you are not sure how to implement is the best way to create bugs.Do it right the first time. If you can’t figure out exactly how it should be done, don’t do it. Keep planning. Writing algorithms you are not sure how to implement is the best way to create bugs.
  My first question is, do you guys often do the quick and dirty thing, and then go back to fix it later; or do you get a hold of yourself and make sure you get the job done well, first and foremost?.
  Do you refactor while coding, or do you refactor after everything's done?
  So the general answer is that I refactor on my own projects as soon as I realize a need for it, and in professional settings I refactor based on the weighted sums of the need for refactoring vs. how much time is available for it.
  In no cases is refactoring done after everything else is done. Not only do most projects have no end (for example, will there ever be a day when there is not a new feature I could add to my game engine?), but those projects that do have an end…end. They get shipped and you move on. You never think, “I could put this amazing app on the App Store right now! But naw I better spend another week just moving code around, even though the resulting product will be the same.” It doesn’t happen.
  When it comes to my own projects, however, I allow myself one exception specifically to accommodate a personality “flaw” of mine.
  Sometimes I am in the mood to do nothing but simple and mundane tasks, and if there aren’t any I simply won’t code anything. I will watch a cartoon or something and wast time.
  But if there are some to do, I will start doing them, and once I get started I get in the mood to do more and more, and end up adding or at least starting new features.
  When I get excited about the end result, sometimes I intentionally copy-paste code instead of moving it into a function (for example) specifically to give me a mundane task that will ultimately end up making me more productive.
  Obviously, if you are a normal human being this will not apply to you, and I recommend being strict on the structure of your code at all times.
  L. Spiro
  Edited by L. Spiro, 24 September 2012 - 05:23 AM.
  My Art: My Music:
  L. Spiro Engine:
  L. Spiro Engine Forums:
  #14 Members - Reputation: 1561
  Posted 24 September 2012 - 12:27 PM
  The second scenario I frequently find myself in, is when a class gets too big (with a fat interface), or a subroutine gets too big. That is usually a sign that some refactoring is needed. This case can be harder, however.
  Doing a refactoring mostly leaves me with a very pleasant feeling. I can stare at the source code and feel pride. If I show it to my friends, they say "of course, how else could it be done?". Lots of effort has been used to find the obvious solution. But I know it is far from easy to find the obvious solution the first time you try. A good refactoring opens up new possibilities and opportunities that were not foreseen..
  Do you refactor while coding, or do you refactor after everything's done?
  That never happens. Unless someone pays your explicitly for it. The curse of having a limited budget or deadline is the usual thing, unfortunately. I think it is common that the "next project/budget" will have to take the consequences of imperfect design. And as this is a limited budget also, it is not unusual to end up in a patch work. If this goes too far, the solution will eventually to start from scratch. Kind of an ultimate refactoring.
  Sharing OpenGL experiences:
  #15 Moderators - Reputation: 27603
  Posted 24 September 2012 - 02:56 PM
  You write code. You consolidate, clarify, and clean up. Then you submit.
  It should be included as a part of the estimates, and in practice is just a very small amount of time. When you see something that needs to be cleaned up, you simply do it. You also tidy up after yourself as you make changes and before you submit.
  Much like a woodworker must clean up scraps as part of the task, so do programmers also need to clean up as they go along. They don't need to allocate extra time "sweep up the scraps and sawdust", it is just a known automatic task that must get done both during development.
  If the wood shop doesn't get swept frequently it becomes dangerous for both injury to the workers and also for disasters like fires. Similarly if code is not regularly cleaned up during development it becomes more difficult to maintain and at risk for disastrous problems.
  Edited by frob, 24 September 2012 - 03:02 PM.
  Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.
  Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.
  #16 Members - Reputation: 551
  Posted 24 September 2012 - 07:20 PM
  [source lang="csharp"]<!-preserve.newline-->#region Description<!-preserve.newline-->/*<!-preserve.newline--> * <!-preserve.newline--> * <!-preserve.newline--> * <!-preserve.newline--> * <!-preserve.newline--> * <!-preserve.newline--> */<!-preserve.newline-->#endregion<!-preserve.newline--><!-preserve.newline-->#region Using Statements<!-preserve.newline-->/* System References :: */<!-preserve.newline-->using System;<!-preserve.newline--><!-preserve.newline-->/* Internal References :: */<!-preserve.newline--><!-preserve.newline-->#endregion<!-preserve.newline--><!-preserve.newline-->namespace MyNamespace<!-preserve.newline-->{<!-preserve.newline--> public class AClass1<!-preserve.newline--> {<!-preserve.newline--> /*-----------------------------------------------------------------------------<!-preserve.newline--> * CONSTRUCTORS & INITIALIZATION ::<!-preserve.newline--> *-----------------------------------------------------------------------------*/<!-preserve.newline--><!-preserve.newline--> public AClass1() { }<!-preserve.newline--><!-preserve.newline--> /*-----------------------------------------------------------------------------<!-preserve.newline--> * FIELDS & PROPERTIES ::<!-preserve.newline--> *-----------------------------------------------------------------------------*/<!-preserve.newline--><!-preserve.newline--><!-preserve.newline--><!-preserve.newline--> /*-----------------------------------------------------------------------------<!-preserve.newline--> * METHODS & IMPLEMENTATIONS ::<!-preserve.newline--> *-----------------------------------------------------------------------------*/<!-preserve.newline--><!-preserve.newline--><!-preserve.newline--><!-preserve.newline--> /*-----------------------------------------------------------------------------*<!-preserve.newline--> *******************************************************************************<!-preserve.newline--> *-----------------------------------------------------------------------------*/<!-preserve.newline--><!-preserve.newline--> } // <-- End of class...<!-preserve.newline-->} // <------ End of namespace...<!-preserve.newline-->[/source]
  You probably either love it or hate it... For some reason I've never liked the convention of putting fields/properties first in a class, followed by constructors followed by methods. Since constructors are the first part of a class to run it only seems logical that they should appear first in the file (to me at least). That's why I do it this way. Every single file in my engine's code base follows this formatting conventions. The only exception is really small types (small classes and structures, enums and "helper" types/files). For me, this just makes things very, very organized and highly readable. I also typically refuse to save and close a file with properly documenting everything of any importance (every publicly exposed member) with XML documentation.
  As for the actual code I try to do things right from the beginning. I try to avoid any sloppy/ugly code. In my opinion, poorly written and sloppy code is not a timer saver...it's a time-waster. Something major is going to break and you're going to have hell sorting it out. If your sloppiness gets too out of control you might end up with a situation where you're better off starting an entirely new solutions and copying over only the good bits of working code and rewriting everything else. And I HATE doing that because it takes forever on a project as large as my engine.
  CEO & Lead Developer at ATCWARE™
  "Project X-1"; a 100% managed, platform-agnostic game & simulation engine
  Please visit our new forums and help us test them and break the ice!
  ___________________________________________________________________________________
  #17 Members - Reputation: 1573
  Posted 25 September 2012 - 05:35 AM
  Most of the above advice is arguably correct when talking about 'tidying up code' but very little of it is about refactoring..
  Seriously, look into refactoring as a rigorous systematic process. It's worth it.
  #18 Moderators - Reputation: 27603
  Posted 25 September 2012 - 11:21 AM
  Depends on your definition of "tidying up".Depends on your definition of "tidying up".
  There's a popular misconception being perpetuated in this thread - that refactoring is 'tidying up code'. It's not. It's a specific term, related to the term 'factor' from mathematics.
  Most of the above advice is arguably correct when talking about 'tidying up code' but very little of it is about refactoring.
  For me that includes all the major steps; removing duplicate code to functions, pushing up to base classes, generalizing code, extracting classes and methods for clarity, etc. To me, that is simply tidying up. All of these are refactorings that don't modify the behavior, but that dramatically clean up the code for future use.
  Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.
  Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.
  #19 Crossbones+ - Reputation: 3754
  Posted 25 September 2012 - 03:01 PM
  My first question is, do you guys often do the quick and dirty thing, and then go back to fix it later; or do you get a hold of yourself and make sure you get the job done well, first and foremost?
  I often do the thing right the first time. Or essentially right. Sometimes doing all the nitty gritty details is counter-productive because of unknowns, risk of change, etc.
  My second question is, what is your attitude about refactoring?
  It is an essential practice to limit code rot.
  Do you refactor while coding, or do you refactor after everything's done?
  - If I'm coding and encounter something that sucks, I'll occasionally take a tangent to refactor it.
  - If I'm coding and encounter something I want to re-use, but it's not quite abstract enough, I'll usually refactor it to handle the new case as well.
  - If I'm fixing a bug, and encounter some root cause that would cause a similar bug to be caused in the future, I'll refactor to fix the root cause rather than just the line that caused the bug.
  - Rarely, I'll go back and clean up something I wrote that isn't related to new development or bugfixing. If it works, leave it be.
  - I will frequently go through and refactor something other people wrote that will assuredly cause bugs in the future, is untestable, or otherwise needs it.
  #20 Members - Reputation: 1573
  Posted 26 September 2012 - 10:31 AM
  removing duplicate code to functions, pushing up to base classes, generalizing code, extracting classes and methods for clarity, etc. To me, that is simply tidying up.
  You can use refactorings to tidy up, sure. But you can also tidy up in ways that are not refactorings, and do refactorings that are nothing to do with tidying up. So I think having a separate specific term is quite useful
  For example: requirements change and you decide to parameterise a function or class further - that's not tidying up, it's preparing the ground for a new feature without changing external behaviour.
  I was prompted to respond to L Spiro's comment that "The only reason to ever refactor is if you simply made a mistake". That's absolutely not true - requirements change. Of course it is perfectly reasonably to argue that the only reason to need to tidy up is if you made a mess. But not all refactoring is tidying up!
  Not just being pedantic, I hope!