Code Quality

Summarized using AI

My favorite Ruby Style Guidelines

Sarah Lima • July 25, 2023 • online

In the video titled "My favorite Ruby Style Guidelines," Sarah Lima, a senior developer and team lead at Talbot, presents a comprehensive discussion on the importance of style guidelines in Ruby programming. She emphasizes that adhering to these guidelines facilitates better code readability and consistency, particularly beneficial for team collaboration and onboarding new developers.

Key Points Discussed:

  • Purpose of Style Guidelines: Sarah explains that style guidelines help improve code readability, maintain consistency across codebases, and reflect real-world usage of Ruby rather than arbitrary choices.

  • Standard Style Configuration: She introduces the concept of using 'Standard,' a gem built on RuboCop, to ensure coding standards are met. By generating a violation report for existing codebases, developers can improve their code incrementally without enforcing all rules at once.

  • Nested Classes and Modules: Sarah advocates for using nested class/module definitions over shorthand versions. She explains that nested definitions help avoid name errors that can occur when constants are defined outside their intended scope.

  • Control Flow Guidelines: She warns against using the for loop unless necessary, as variables defined within its scope are accessible outside, which could lead to unintended side effects. Instead, she suggests using the each method, which maintains scope isolation.

  • Using Shorthand for Blocks: Sarah encourages the use of the shorthand notation for blocks when a method call is the only operation, viewing it as both a simpler and more elegant solution.

  • Defining Concepts Outside of Blocks: She notes the risk of defining constants inside blocks, which can lead to naming conflicts. Instead, Sarah suggests defining concepts outside the block to avoid such issues.

  • Avoiding Monkey Patching: Finally, Sarah addresses the risks of monkey patching, where built-in classes or methods are modified. While it might seem convenient, she argues that it can cause unforeseen issues and maintenance headaches. Subclassing and encapsulation are preferred approaches for extending functionality.

Conclusions:

Sarah concludes by reiterating the value of following Ruby style guidelines for enhancing code quality and team collaboration. Audiences are encouraged to connect with her on LinkedIn for further discussions. The session underscores the importance of being aware of best practices in Ruby programming to avoid common pitfalls and to build maintainable, clean code.

My favorite Ruby Style Guidelines
Sarah Lima • July 25, 2023 • online

Following style guidelines helps programmers avoid time-consuming discussions on trivial matters and facilitates collaboration as newcomers can quickly familiarize themselves with the code and start contributing effectively.

We're gonna dive into some of my favorite ruby style guidelines, discussing the rationale and the technical aspects that underpin them, and how they help us avoid common pitfalls.

https://www.wnb-rb.dev/meetups/2023/07/25

WNB.rb Meetup

00:00:00.000 everybody
00:00:01.040 my name is Sarah I'm just a school
00:00:04.020 farming can everybody
00:00:07.799 yeah okay thanks
00:00:10.620 um I am a Brazilian developer living in
00:00:12.960 Brazil currently
00:00:14.580 um I am a senior developer in team lead
00:00:17.820 at Talbot
00:00:19.160 and uh I have worked I've been working
00:00:23.820 with Regus for Ruby on radios for like
00:00:26.699 in total for I think four years now but
00:00:30.420 I have worked with other languages as
00:00:33.000 well like python Java
00:00:35.340 JavaScript as well and this is my first
00:00:38.460 time talking in English uh in the Meetup
00:00:41.399 um I'm not a native speaker so please
00:00:43.320 bear with me
00:00:44.879 I'm gonna do my best
00:00:47.219 uh okay stats 130 uh my time so I'm
00:00:51.660 gonna strive to wrap this up in 15
00:00:54.960 minutes
00:00:55.860 all right so the CM of my talk is my
00:00:58.860 favorite Ruby Style Guidelines lately
00:01:01.440 they have been my favorite languages
00:01:03.780 because they
00:01:06.060 um when I was checking out the Ruby
00:01:09.960 style guide
00:01:11.360 website I just like scrolling I saw that
00:01:16.140 there were some things that I didn't
00:01:18.479 understand deeply and so I felt drawn to
00:01:22.860 okay let's let me dive into this and
00:01:26.340 understand
00:01:28.439 why the reasoning behind those
00:01:31.500 guidelines
00:01:33.000 so these are gonna be my sources today
00:01:35.460 uh the Ruby style.guide website and the
00:01:39.479 thought guides Ripple if you don't know
00:01:42.720 about it then including Ruby you may
00:01:45.060 want to check it out I think it's very
00:01:46.860 helpful
00:01:48.900 and they thought about guys they cover a
00:01:53.520 lot of aspects of working together in um
00:01:58.560 um programming while programming style
00:02:00.240 but I'm gonna Focus here on the aerobic
00:02:03.240 section
00:02:04.619 and yeah let's let's start
00:02:08.039 so why guidelines wife bother following
00:02:11.280 guidelines because code is red much more
00:02:14.459 than more often than it's Raven and
00:02:18.420 guidelines from tabat Guides and Ruby
00:02:21.660 style they provide us
00:02:23.520 um they help us to improve the
00:02:25.640 readability of our code uh help us make
00:02:29.340 it consistent across the wide spectrum
00:02:31.800 of Ruby code
00:02:33.660 and they are also meant to reflect real
00:02:36.540 world usage of Ruby instead of a random
00:02:39.239 ideo
00:02:41.340 so my first guideline I want to share
00:02:45.599 with you very basic very simple just to
00:02:47.640 get started but that's gonna help you
00:02:49.500 like just not have to think about a lot
00:02:52.140 of other guidelines is using standard
00:02:56.280 um this is from the taba guides it uh
00:02:59.220 standard is a link there and for matter
00:03:01.879 built on Robocop and provides an
00:03:05.180 unconfigurable configuration
00:03:07.700 for our styling
00:03:12.800 to get started with standard you can
00:03:15.900 generate a to-do
00:03:17.519 um usually we work with
00:03:20.300 repositories with code bases that
00:03:22.440 already exist and already don't know do
00:03:25.560 not follow uh any guidelines so you can
00:03:29.580 just after installing standard you can
00:03:33.180 generate a to-do and that's gonna like
00:03:35.519 generate a file a listing all the
00:03:38.879 violations there is in your code base
00:03:41.220 there are in equal based and so that's
00:03:44.400 going to be much easier for you to like
00:03:46.500 not introduce new violations
00:03:49.739 and at the same time not have to worry
00:03:52.560 to fix everything before uh moving ahead
00:03:55.739 and
00:03:57.860 improving um step by step
00:04:01.080 so if you use GitHub and GitHub actions
00:04:04.080 you can add standard
00:04:06.599 uh RB to your workflow and extender will
00:04:11.640 run on your every PR guaranteeing that
00:04:13.980 we are not introducing violations
00:04:18.000 okay so first things first move on
00:04:21.419 moving on next uh the next guideline is
00:04:24.780 about preferring nested classes and
00:04:27.540 module definitions over the shotgun
00:04:29.580 version so what does that mean
00:04:32.340 oh and this is from the top of guides
00:04:35.419 so first on the left it's the nested
00:04:40.020 module in class definitions so you
00:04:42.540 define module a Class B and Define your
00:04:45.479 body
00:04:46.680 and on the right we see the
00:04:50.419 shorthand version
00:04:52.639 so why should we prefer the nested
00:04:56.460 version on the left
00:04:59.300 one of the reasons I think most
00:05:01.979 important that may buy to you if you
00:05:04.680 don't follow these guideline is constant
00:05:07.680 local
00:05:09.060 so I have an example here we have a code
00:05:13.340 on where we are defining our module a
00:05:16.860 for instance and inside uh the module a
00:05:19.919 we Define a constant
00:05:21.720 and then if we Define uh a second module
00:05:26.340 module B we say a column column B and
00:05:31.320 Define a method called test and we try
00:05:35.039 to call this test method
00:05:39.139 can you see my pointer
00:05:42.120 yep cool uh under that you see that we
00:05:46.680 are going to have a name error uh saying
00:05:49.380 additional initialize constant a b
00:05:52.919 constant
00:05:54.240 uh so you may
00:05:56.460 run across this and say what this
00:05:59.340 happened a year I don't know
00:06:00.840 but if you define a nested version
00:06:04.580 let's say module a module C and then
00:06:07.740 Define your test method and call use
00:06:10.320 your consent this test method is going
00:06:12.660 to return your constant and then here
00:06:14.639 you you're gonna have your expected
00:06:16.979 Behavior
00:06:18.060 if anybody has seen that error glitter
00:06:22.319 on the chat
00:06:24.120 so there is one other reason about
00:06:26.819 syntax or something but I don't fully
00:06:29.100 understand what zip tags are but I'm
00:06:30.660 gonna
00:06:32.100 um
00:06:33.240 dive into this later
00:06:35.520 um not here in the factory just like for
00:06:37.440 my own learning
00:06:40.860 okay so this is
00:06:43.680 um
00:06:45.060 uh one the second guideline let's move
00:06:48.960 on to the curve about flow of control
00:06:52.440 I didn't
00:06:54.000 um explain things very well please feel
00:06:56.699 free to ask questions at the end
00:06:59.520 so uh this guideline is about not using
00:07:02.880 for unless you know exactly why
00:07:06.780 so let's give an example example here if
00:07:10.319 we Define a ray here and we iterate over
00:07:16.319 it with the four
00:07:19.080 um
00:07:20.039 we will see that the elements
00:07:24.599 uh Define
00:07:26.479 inside that four are gonna be accessible
00:07:29.400 outside the Forum and that's not what we
00:07:32.699 want usually of course there may be a
00:07:36.180 use case for that but we uh usually
00:07:39.539 expect especially if you're coming from
00:07:41.580 other languages that the
00:07:44.580 buy items we are iterating uh inside
00:07:47.940 therefore we expect them to be uh
00:07:51.360 defined only under the scope of the four
00:07:53.580 Loop
00:07:55.259 so why how can we avoid that we can use
00:07:58.740 either
00:08:00.000 um
00:08:00.960 we can use for instance each and then uh
00:08:04.319 the element item is not going to be uh
00:08:07.740 defined outside the our
00:08:10.139 each
00:08:11.819 um
00:08:12.660 top
00:08:15.360 cool
00:08:17.520 much better so moving forward to
00:08:20.940 um next one about block rocks and
00:08:23.520 lambdas we should use the protocol
00:08:27.360 shorthand
00:08:28.740 um when they call method is the only
00:08:30.479 operation of a block so what does that
00:08:33.599 mean
00:08:34.740 this one is not
00:08:36.539 so complex or interesting I just put it
00:08:40.200 here because I think I remember when I
00:08:43.440 first learned about these like 60 years
00:08:47.339 ago I've found it so beautiful like so
00:08:49.740 simple so elegant and was like the time
00:08:52.740 when I fell in love with Ruby
00:08:54.959 so we have here an array and we are
00:08:58.080 mapping with it and instead of uh
00:09:00.899 defining
00:09:02.220 and the calling name dot a case we can
00:09:05.339 just uh to straight
00:09:08.160 um
00:09:09.260 a problem
00:09:13.680 with the I don't know the name of this
00:09:17.040 symbol in English and a column and then
00:09:19.380 you call the method you're uh you're
00:09:22.320 going to follow
00:09:24.300 cool much better at least for me
00:09:28.980 and moving on next we have defining
00:09:32.700 Concepts within a block
00:09:34.440 I have been beaten by that before too
00:09:38.339 so
00:09:39.480 um
00:09:40.380 these guidelines mentions that the block
00:09:44.040 scope does not isolate or name space the
00:09:47.040 articles in any way
00:09:49.680 so if you're writing for instance a rake
00:09:52.740 task if you are using range in a rails
00:09:55.440 application for instance and you define
00:09:58.100 a task let's say inviting
00:10:01.519 wmb members to meet up and we Define
00:10:06.000 um an array called members emails
00:10:08.839 these uh members in Leo
00:10:11.540 constant is going to be available
00:10:13.860 outside of our blog so that may be uh
00:10:18.360 issue an issue for you if you have like
00:10:20.279 another
00:10:22.440 um task let's say uh if we want to
00:10:25.920 Define members in there again we're
00:10:27.779 gonna have a problem because these two
00:10:31.220 constants exist in the same
00:10:34.440 um they may like crash
00:10:37.200 so instead of using uh we find a
00:10:40.680 constant inside our task we can Define
00:10:43.080 the concept outside of it or we can just
00:10:46.380 Define a variable or a method
00:10:50.880 so
00:10:52.440 much better
00:10:55.740 all right so we have a few minutes and
00:10:58.740 let's move on to the next one
00:11:00.839 um avoiding multiplexing this is from
00:11:03.899 Dabba guides
00:11:06.200 and I haven't seen monkey fighting in my
00:11:09.959 uh like last projects thankfully
00:11:14.519 and so what it is monkey patching if you
00:11:17.160 don't know about it it is a technique
00:11:20.100 about modifying or extending Beauty in
00:11:22.320 classes and methods around time
00:11:25.100 so uh let's say that
00:11:28.079 uh we will now have a new behavior for
00:11:32.700 the string class uh that's I think a
00:11:35.279 very used very common example on monkey
00:11:39.959 patching let's say that we were known
00:11:42.899 and I met the string class called let's
00:11:45.660 see
00:11:47.279 um a new way of capitalizing things like
00:11:49.920 uh
00:11:52.579 okay I'm not gonna have an example here
00:11:55.260 uh right under
00:11:57.660 in my head but okay let's say we wanna
00:12:01.019 modify our extend the stream class from
00:12:04.200 the Ruby building classes
00:12:07.079 so this looks convenient at first but
00:12:12.480 um
00:12:13.500 this can lead to numerous issues and
00:12:15.899 make gold maintenance challenging
00:12:18.600 just because
00:12:20.519 um it linked to conflicts
00:12:23.100 um unexpected behaviors and difficult to
00:12:25.740 debug errors
00:12:28.079 so we may introduce an annotational
00:12:31.740 conflicts when like
00:12:34.800 um you multiply the string class and
00:12:37.680 then you saw a third-party library that
00:12:41.220 also modifies it and introduces a
00:12:43.200 different behavior for the method you
00:12:45.720 introduce
00:12:47.339 and also
00:12:49.139 um when we want to debug something we
00:12:52.920 have to look for uh functionality
00:12:56.100 scattered across various files
00:13:00.000 so instead of monkey patching we can
00:13:02.880 prefer subclassing and encapsulation
00:13:06.600 for adding new features and it provides
00:13:09.600 a more organized and predictable
00:13:11.700 approach to extending social bodies in
00:13:15.240 our Roblox
00:13:18.560 and that yeah that was it thank you uh
00:13:24.180 I'm available on LinkedIn please do
00:13:27.300 um friendly there I don't know if it's
00:13:29.040 called friend connect with me there I'll
00:13:31.980 be glad to
00:13:33.959 um
00:13:34.860 could continue to be connected to all
00:13:37.740 living
00:13:39.779 thank you questions
Explore all talks recorded at WNB.rb Meetup
+20