He makes the point, using some good examples from different languages, we can live with understandable code, and there is a cost to having Clean Code, particularly when you have it.

Thinking about it a bit, it takes a bit of work to convert code into Understandable Code. Typically this is what happens when you do a series of refactorings and general clean up.

In order to take that code to Clean Code you’d need to first make it Understandable and then go back through it to clean it up even more. Looking through the example from Clean Code for Args, I’m afraid that Clean Code can even be taken too far. For a long lived system that has its requirements mostly fixed, I can see the benefits of Clean Code. Most of the systems I see, especially in Rails, are more fluid and changing so putting in the time to make all of the code Clean would be overkill.

1. Untested classes
2. Untested methods
3. Untested lines or conditions

When I was refactoring Redmine I used all three of these with rcov to help find places to refactor. Several times these ended up being completely untested classes or methods and I remember one time where a major class wasn’t even loaded during the tests.

Untested conditions (#3) is a great way to do simple extract methods. Like John says in the article, many of these conditions are extra guard conditions. In my opinion, many of those could be refactored to a separate utility method.

The goal of refactoring is not simply to reduce the lines of code, it is to make the code easier to work with in the future. This may sometimes mean writing more lines of code. You might take 5 lines of code and generate 15 lines by creating additional functions or objects…

Krishna Kumar

Whenever you start counting the number of lines of code added or removed, then you are measuring the wrong thing (1). I’ve seen some people reject great refactorings because they added more lines of code. Just remember that refactoring isn’t about reducing the size of your code, it’s about increasing the quality of the code. Size doesn’t matter.

(1) Unless you’re removing a ton of code by using a standard library instead of custom code. e.g. removing 1,000 lines of custom authentication in favor of a authentication gem.

• Has support for:
  • controller renames
  • controller action renames
  • model renames
• is Rails 3 only
• supports rspec tests only

gem install rails_refactor

How To Score Your Rails App’s Complexity Before Refactoring

By Eric Davis — October 27th, 2010

In Tutorials

Every Rails developer must refactor their Rails code at some time. Ruby’s dynamic nature makes it difficult for generic tools to understand what Ruby is doing though. Once you add Rails macros and metaprogramming into the mix you really need specialized tools when refactoring Ruby.

I’ve posted about using flog to analyze and score a Rails application before refactoring to RailsInside.com

Everyday Rails

Everyday Rails: Get stuff done as a web developer.

3 Rails refactoring tools

September 27, 2010

Refactoring—the practice of making your working code better and more manageable through better design choices—is an important part of software development. It’s core to test-driven and behavior-driven methods, but if you’re not yet following the red-green-recycle mantra in your development, you may have yet to experience refactoring in practice. There are plenty of resources on refactoring; today I want to share three tools to help you get started with this technique in your Ruby on Rails projects.

Aaron Summer talks about a few Refactoring tools that he’s used when refactoring Rails.

Reek Wiki

• Attribute
• Basic Smell Options
• Class Variable
• Code Smells
• Command Line Options
• Configuration Files
• Control Couple
• Data Clump
• Developer API
• Duplication
• Feature Envy
• Getting Started
• Home
• Installation
• Irresponsible Module
• Large Class
• Long Method
• Long Parameter List
• Mailing List
• Nested Iterators
• Non ASCII source files
• Project Dashboard
• Rake Task
• RDoc
• Reek Driven Development
• Ruby 1.9
• Simulated Polymorphism
• Uncommunicative Name
• Utility Function
• Working with Rails
• YAML Reports

The Reek wiki has some good documentation on the different types of ruby refactorings.

http://www.refactoringredmine.com/

Don’t walk.  Run.

Better yet, jetpack.

Regardless what your language of choice is, this well structured bit of work on the subject of refactoring will teach about the tools, techniques, and most importantly, the thought processes critical to your excellence in this often overlooked craft.

What’s more, all of the examples are shown using Redmine, a free open source project management tool which is part of the mission critical daily workflow for thousands of businesses, internationally.

At least, that’s the line I imagine Don Draper would serve, like expensive whiskey to a rich client in a silk suit.  Truth is, anyone who has heard about the importance of refactoring again and again, but isn’t entirely sure where or how to start, would do well to read this book…

Cory Flanigan reviews Refactoring Redmine over on his blog. Make sure to bring your jetpacks.

Normally a book will have an acknowledgments section where the author lists all of the people they want to thank. But that’s always seemed odd to me, since the only people who buy the book can actually see that section. Of those people, how many actually read through the acknowledgments section? I know I rarely do.

So instead, I want to take the time to publicly thank everyone who has helped turn Refactoring Redmine into a successful ebook….

There are always many people who work behind the scenes when something is created.

Refactoring Redmine, the ebook – 82 Real World Ruby on Rails Refactorings
www.refactoringredmine.com

• コンピュータ・IT
• 16 users

Looks like Refactoring Redmine got picked on the Japanese bookmarking site Hatena.