From the course: Agile Software Development: Clean Coding Practices

Line wrapping

From the course: Agile Software Development: Clean Coding Practices

Start my 1-month free trial

Line wrapping

- [Instructor] One thing that will make your source files very difficult to read is if the reader has to scroll left to right in order to read your code. The way the editor is configured on my screen I have to scroll to the right quite a bit if I want to be able to read this file. Let's make some edits to this file so the lines fit with an 80 column boundary. That's the limit that I like to use on my projects, and it's one that is common across the industry. Some people advocate for longer lines with the justification that the 80 character limit is a hold-over from when programming was a task that was performed by computers that could only display 80 characters at a time. They suggest that teams adopt a different boundary for deciding when a line is too long. While I understand this reasoning, I still prefer 80 characters because I have little control over the context where my code is going to be read in the future. Whatever the limit that your team decides on, the rules for wrapping lines are the same. Let's start with line 26 and work through some of the long lines near the top of this file. Any time a method's parameters wrap past the 80 character boundary, like it is here with this call to LoadableClass, I prefer wrapping every parameter on its own line. Un-indent the closing parenthesis for the method call to give a visual indication that the long method call is finished. We can now repeat this in the next two calls to LoadableClass. There. Now we don't have to scroll from left to right to see all the parameters that were passed into these method calls. Line 60 is too long because the class that MultiOutputRegressionEvaluator inherits from is too long. Let's move it down one line. The method definition on line 75 has some parameter definitions that are beyond the 80 character mark. Let's apply the same rules that we did above for method calls to clean this up. Now that each parameter is on its own line the call to the base constructor can be moved up a line. Let's skip down to like 94 where there's an if statement. If you're following along, feel free to go back later and wrap all the lines that we've skipped to get some extra practice. For now though, it's best that you wait because your line numbers will no longer match my line numbers. Let's make this if statement fit within the boundary. Now there's a small issue with this if statement because it doesn't have open and closing braces. It makes things look confusing. Let's add open and close braces to clear things up. Now let's jump down to the method and GetOverallMetricColumns on line 115. Within that method, let's wrap a few calls to the constructor for the MetricColumn class. Now this line includes a call to the Regex constructor so we're going to wrap that following the rules that we've used before, where the parameters for the Regex constructor are invented one level beyond where they are used. There, now it's easier to see that while calling the constructor for MetricColumn, this code is calling out to some other methods as well. This was much harder to see before, especially without scrolling back and forth. The rest of the lines in this method give us a bit of before and after. Compare the lines that we just wrapped to the lines that appear below them. The call that we wrapped is much easier to read. Applying this technique to your code will make it easy to read as well.

Contents