Search
Refactoring
The worst Ruby codes I've seen in my life
Edit
#ruby
#code-quality
#refactoring
#object-oriented-programming-oop
#naming
#debugging
#business-logic
Summarized using AI

The worst Ruby codes I've seen in my life

Fernando Hamasaki de Amorim • December 11, 2015 • Chuo-ku, Tokyo, Japan

The Worst Ruby Codes I've Seen in My Life

In this presentation by Fernando Hamasaki de Amorim at RubyKaigi 2015, the focus is on identifying and analyzing poor Ruby code practices, particularly those stemming from WOP (Workaround-Oriented Programming). While Ruby is generally celebrated for its clarity and elegance, Hamasaki points out that the misuse of workarounds can lead to significant code issues and complexity.

Key Points Discussed:

  • Definition of WOP: WOP refers to the use of workarounds and patches in coding, often arising from advanced problems in software development.

  • Experienced Programmers at Fault: The examples presented are drawn from the work of seasoned developers, illustrating that even those with experience can create problematic code.

  • Example of Poor Code - Credit Card Masking: A method to mask credit card numbers is criticized for its complex implementation, as it modifies the original variable instead of simply returning the masked version. This can lead to unintended consequences in other parts of the application.

  • Rails Controller Flow: A Rails controller's action for domain creation is highlighted for its convoluted logic. The presentation suggests simplifying the flow to prioritize readability by discarding complex error handling paths.

  • Confusing Class Design: A poorly constructed Ruby class is discussed, particularly its constructor which requires certain keys in a hash. Hamasaki recommends using the fetch method for clearer error handling and improved design, advocating for clearer definitions of class methods to avoid confusion.

  • Naming Conventions: Misleading method names are critiqued, exemplifying how expectations may not align with actual functionality, resulting in potential misuse of methods.

Conclusions and Takeaways:

Hamasaki emphasizes the importance of clarity in Ruby programming. Good practices should include avoiding WOP, utilizing clear naming conventions, and establishing design structures that promote straightforward logic flows. By learning from examples of bad code, developers can improve their craft and create cleaner, more maintainable applications.

The worst Ruby codes I've seen in my life
Fernando Hamasaki de Amorim • December 11, 2015 • Chuo-ku, Tokyo, Japan

http://rubykaigi.org/2015/presentations/prodis

Most applications written in Ruby are great, but also exists evil code applying WOP techniques. There are many workarounds in several programming languages, but in Ruby, when it happens, the proportion is bigger. It's very easy to write Ruby code with collateral damage.

You will see a collection of bad Ruby codes, with a description of how these codes affected negatively their applications and the solutions to fix and avoid them. Long classes, coupling, misapplication of OO, illegible code, tangled flows, naming issues and other things you can ever imagine are examples what you'll get.

RubyKaigi 2015

00:00:00.000 Hi everybody! I am Fernando Hamasaki, and I have been developing web applications for 15 years. I have written real Ruby code since 2009 and I work at Locaweb, the biggest hosting company in Brazil.
00:00:06.029 So, let's see the term WOP. Who knows what WOP is? Who knows about workarounds in object-oriented programming? Who here is still using WOP?
00:00:23.490 WOP, or Workaround-Oriented Programming, is an advanced technique in software development that uses various kinds of workarounds and patches. Evil code can stem from bad application design and complicated flow.
00:00:36.510 The examples I will show are from experienced programmers, not beginners. One of the first examples is masking credit card numbers.
00:01:11.010 We have an RSpec test that includes a method to mask credit card details. The method receives a credit card number and only reveals the last four digits. A possibly simple implementation could take the string representation of the number and replace the initial digits with asterisks. However, the WOP implementation iterates over the string and replaces each digit with an asterisk until it reaches the last four digits.
00:02:23.510 While it technically works, it has downsides. For instance, if you check the original variable after running the method, you'll find that the value of the number parameter has changed inside the method.
00:03:10.500 Next, we have a Rails controller that has an action to create two domains based on names found in the database. If no sites are found with blank names, it continues, and if it cannot find sites, it returns a message back.
00:03:56.230 The flow here is not so clear, especially because there is a return statement followed by an 'else' condition which can be confusing. If sites are found, it builds the domain and saves it, returning a success message. If it cannot save, it returns a message indicating that as well.
00:04:28.389 To improve the readability, we should discard error paths and place the success path at the end of the method. This makes it much clearer. In Ruby, clarity is vital.
00:05:25.960 Now let’s look at a poorly designed Ruby class. First, the constructor receives a hash where email and token keys are required. If they do not exist, it will raise an ArgumentError. Moreover, the options instance variable is widely used across multiple methods.
00:06:14.220 The best approach to ensure required values in a hash is to use the fetch method. If the key is absent, an error will be raised. There are also many methods that dynamically create attribute getters for each instance variable, and this could be improved by having a clearer definition.
00:07:23.199 However, this class is confusing and very hard to read.
00:07:34.410 Next, we have another class causing confusion with method names. It has parameters and various methods that are not clearly defined leading to dangerous code.
00:08:02.280 For instance, the import method is significantly different than what one might expect, resulting in misuse. It’s crucial to ensure clarity in naming functions.”},{
Fernando Hamasaki de Amorim
@prodis
Explore all talks recorded at RubyKaigi 2015
+47