DEV Community: Gustavo Araujo

Code Review Best Practices: When (and When Not) to Use "Request Changes"

Gustavo Araujo — Wed, 29 Oct 2025 14:09:03 +0000

A code review is meant to help teams write better code together. But when reviewers misuse the “Request Changes” button, it turns a learning process into a power move, and code reviews aren’t about control, they’re about collaboration.

When you open a pull request, you’re saying "Hey, here’s my idea — what do you think?". You’re open to feedback (and hopefully expecting it). That’s how teams grow together and keep their codebase healthy.

The Real Purpose of Code Reviews

At their core, code reviews serve two simple principles:

Write code for people, not machines.

Your teammates should be able to understand your code without decoding your brain.
Share knowledge and align understanding.

Every review is a chance to spread context — not just spot mistakes.

If your review doesn’t move the team forward on at least one of these two fronts, it’s probably not doing its job.

Not Every Comment Deserves a "Request Changes"

During a review, you’ll often find things you’d write differently. That’s natural.

We all have preferences — naming styles, indentation, function length, code structure. But your way isn’t always the way. And that’s where many reviewers slip into “authority mode.”

When you hit Request Changes for something subjective, you stop the flow of collaboration. You’re not saying "Here’s an idea to discuss" — you’re saying "My way or the highway."

That button literally blocks the PR from merging until you approve it again. It’s a tool for addressing critical issues, not for expressing opinions.

When “Request Changes” Makes Sense

There are legitimate times to use it:

The code breaks the build or could harm production.
There’s a security risk.
It violates a major architectural rule that needs immediate attention.

In those cases, you’re protecting the system, not your ego.

Use “Request Changes” to safeguard the environment, not to enforce personal taste.

For Everything Else: Start a Conversation

If your feedback is about code design, naming, or readability, explain why it matters. Reference documentation, articles, or past discussions that give your opinion context. A simple “I’d prefer it this way” doesn’t teach anyone anything.

When feedback feels like an exchange instead of a rejection, it builds trust, and trust leads to better code.

Standardize What’s Subjective

If the same style debates keep coming up, automate them.

Set up linters and formatters in your CI pipeline. That removes bikeshedding from the human layer and frees reviews to focus on what really matters: logic, architecture, and clarity.

A Small Tip: Try Conventional Comments

If you want to make your review comments clearer and friendlier, check out Conventional Comments.

It helps you structure feedback with prefixes like:

nitpick: for small suggestions
question: for clarifications
suggestion: for improvements

This format makes your intent explicit and keeps discussions constructive.

Final Thought

Don’t Weaponize the Request Changes button in Code Reviews. A good review isn’t about winning an argument, it’s about helping each other write better software.
Avoid “Request Changes” unless the system truly depends on it. Everything else deserves a conversation, not a command.

GitHub's notifications on your Discord Server

Gustavo Araujo — Fri, 01 Apr 2022 01:02:09 +0000

I really love Discord and use it as a communication tool for personal projects with my friends and teammates. Sometimes I wonder: Do we have an App for Discord equivalent to GitHub App for Slack (former Pull Panda)?

So, I noticed that actually we don’t have it, for simple reasons: We can integrate GitHub Webhook to send events directly to Discord Webhook. Simple and functional. So, let's do it!

1. Create the Webhook

The first step is to create the Webhook on your Discord server to receive the events from GitHub:

Go to your discord Server Settings;
Click on the Integrations item on the sidebar;
Hit the Create Webhook button;
Fill the name field (I used GitHub Integration) and select a channel to post the messages;
Click on Save Changes button;
Then click on Copy Webhook URL.

2. Set up the Webhook on GitHub

Now, you’ll need to configure GitHub to send the events to Discord Webhook:

Navigate to your organization (or repository) on GitHub
Click the Settings tab;
Click the Webhooks item on sidebar;
Hit the Add Webhook button on the top of the page;
Fill the Payload URL field with the URL copied in the step above (Step 1);
Add /github at the end of the URL (It’s very important!);
In Content Type select Application/JSON;
You can leave the Secret field empty;
In Event Triggers if you select:
- Just the push event you’ll receive new pushed commits.
- Everything you’ll receive everything, like new Pull Requests opened, workflows, etc.
- Let me select individual events you can choose.
Hit the Add Webhook button.

You’re all set! You’ll get GitHub events notifications on your Discord channel.

If you have any questions, you can reach me on Twitter, or you can just use the comments section below 🙂

I hope I was helpful, and thank you for reading.

RuboCop: How to install and configure

Gustavo Araujo — Tue, 15 Mar 2022 14:07:51 +0000

That Code quality is important, and any high-performing team knows it, but do you follow a guideline to standardize your codebase and make sure that everyone is going and looking in the same direction?

Making a brief introduction, this is the goal of a linter: A tool that analyzes your source code to identify programming errors, bugs, and suspicious constructions (Wikipedia).

The main objective is to ensure that your code follows the same rules and practices, to look like the entire code was written by the same person.

In a large variety of linters from Ruby, we have RuboCop (available as a gem) that follows the best practices described in The Ruby Style Guide.

One of the advantages of using a linter is to save time reviewing code because it prevents small issues like inconsistent variable names and practices during the development process. With that, the code review is more efficient, and it can be focused on implementations and features requirements.

Starting using RuboCop is very straightforward and doesn’t depend on anyone else to setup it. You can install the gem and run it immediately during your workflow.

Installation

To install the RuboCop, it’s quick and easy. Let's consider here that all your Ruby environment is working, so just execute the following command to install the latest RuboCop version available:

$ gem install rubocop

RuboCop officially supports the MRI 2.5+ and jRuby 9.2+ implementations. You can also install directly in the project using Bundler, adding the gem to your Gemfile, and then run bundle install.

Configuration

The RuboCop behavior can be controlled in the .rubocop.yml file in the root path where you want to execute it. In this file, you can enable/disable certain cops (rules) or change their behavior.

All cops are grouped into departments: Style, Layout, Lint, Naming, Security, Metrics, Migration, Bundler, and Gemspec. You can read about the cops and their departments in the documentation. For reference purposes, check the configuration file that we use in SourceLevel in our linter’s configuration repository.

The .rubocop.yml file has the following structure:

inherit_from: ../.rubocop.yml

require: rubocop-rails

Style/Encoding:
  Enabled: false

Layout/LineLength:
  Max: 99

...

Note 1: We’re using inherit_from to inherit all defined cops in the other file. See more in the documentation.
Note 2: If you’re using **Rails, it’s important to require the rubocop-rails extension (remember to add it to your Gemfile), which will force RuboCop to follow the conventions and good practices defined by the Rails community.

By default, when executed, the RuboCop looks for .rubocop.yml in the current directory, then in your home path (~/.rubocop.yml), and in the last case it will use the defaults. More details about RuboCop’s configuration file can be found on the documentation.

If you want to create your configuration file, which I encourage, a good starting point is to use the configuration available in the RuboCop repository as a reference. You can review cop by cop and configure what suits you. Just remember to check the cop availability for the version of RuboCop that you’re using.

Keep in mind that style rules that belong to the Style namespace are configurable and optional. A good recommendation is that these rules need to be discussed and defined with the entire team, not by a single person.

It’s nice to mention that you can write your own cops, called Custom Cops. With that, you can create your own rules, defining your practices to ensure that they will be followed. You can find more information about this process in documentation.

Usage

To use the RuboCop you just need to navigate to the directory where you want to run the linter, and execute:

$ rubocop

You can specify a file/path too:

$ rubocop lib/file.rb

It’s possible to specify a list of directories and files:

$ rubocop app/ spec/ lib/file.rb

After running RuboCop, you’ll get an output with offenses, like:

Offenses:

test.rb:1:1: C: Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.
def badName
^
test.rb:1:5: C: Naming/MethodName: Use snake_case for method names.
def badName
    ^^^^^^^
test.rb:2:3: C: Style/GuardClause: Use a guard clause instead of wrapping the code inside a conditional expression.
  if something
  ^^
test.rb:2:3: C: Style/IfUnlessModifier: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
  if something
  ^^
test.rb:4:5: W: Layout/EndAlignment: end at 4, 4 is not aligned with if at 2, 2.
    end
    ^^^

1 file inspected, 5 offenses detected

Autocorrecting

A great thing about RuboCop is the autocorrecting feature. This option fix automatically all possible offenses in your code, based on defined rules. In our case, we use -a that fix safe offenses, but you can be more optimistic and use -A to fix all offenses (including unsafe), but you need to use it with caution.

To use them, you just need to run RuboCop with this autocorrecting argument:

$ rubocop --auto-correct
# or
$ rubocop -a

You can check all RoboCop’s arguments using the --help:

$ rubocop --help

Just for linking purposes, you can check the documentation to know more about autocorrect.

Integrating with other tools

RuboCop integrates with many other tools. You may integrate it into your code editor to run it every time you save a file, and you'll immediately get its insights.

For a list of currently supported code editors, you can check this page on documentation, and if your favorite is not listed, it’s a great opportunity to contribute to RuboCop implementing an integration.

Another great usage is creating a Git Hook to run RuboCop before every commit. You can also setup RuboCop to be run into your Continuous Integration service (such as GitHub Actions) to have some insights for every commit. In all cases, more details can be found in the documentation.

I hope you enjoyed the content, and thank you for reading.

Rubocop: Como instalar e configurar

Gustavo Araujo — Sun, 09 Jan 2022 17:20:54 +0000

Qualidade de código é importante, e toda equipe de alta performance sabe disso, mas você segue algum guia para padronizar sua base de código e garantir que todos estão indo e olhando pra mesma direção?

Fazendo uma breve introdução, este é o objetivo de um linter: Uma ferramenta para analisar seu código-fonte e identificar erros de programação, bugs e inconsistências (Wikipedia).

O objetivo principal é garantir que seu código siga as mesmas regras e práticas, para parecer que todo o código foi escrito pela mesma pessoa.

Em uma grande variedade de linters de Ruby, temos o RuboCop (disponível como uma gem) que segue as boas práticas descritas no The Ruby Style Guide

Uma das vantagens de usar um linter, é salvar tempo revisando código, pois ele previne pequenos problemas como inconsistências em nomes de variáveis e práticas durante o processo de desenvolvimento. Com isso, a revisão de código é mais eficiente, e pode ser focada nas implementações e requisitos de funcionalidades.

Começar a usar o Rubocop é bastante simples e não depende de ninguém mais para configura-lo. Você pode instalar a gem e roda-la instantaneamente no seu fluxo de trabalho.

Instalação

Para instalar o Rubocop, é bem rápido e simples. Vamos considerar aqui que todo o seu setup Ruby esteja funcional, então execute o seguinte comando para instalar a última versão disponível:

$ gem install rubocop

RuboCop oficialmente suporta as implementações MRI 2.5+ e jRuby 9.2+. Você também pode instala-lo diretamente no seu projeto usando o Bundler, adicionando a gem ao seu arquivo Gemfile, e rodando bundle install.

Configuração

O comportamento do Rubocop pode ser controlado pelo arquivo .rubocop.yml na raiz do projeto onde você deseja executá-lo. É nesse arquivo que você consegue habilitar/desabilitar certas cops (regras) ou alterar seu comportamento.

Todas as cops são agrupadas em departamentos: Style, Layout, Lint, Naming, Security, Metrics, Migration, Bundler, e Gemspec. Você pode ler melhores sobre as cops e seus agrupamentos na documentação. Por propósitos de referência, você pode consultar o arquivo que usamos na SourceLevel em nosso repositório de configuração de linters.

O arquivo .rubocop.yml tem a seguinte estrutura:

inherit_from: ../.rubocop.yml

require: rubocop-rails

Style/Encoding:
  Enabled: false

Layout/LineLength:
  Max: 99
...

Nota 1: Usamos o inherit_from para usar as cops já definidas de um outro arquivo. Mais detalhes na documentação.
Nota 2: Se você usa Rails, é importante fazer o require da extensão rubocop-rails (Lembre-se de adiciona-la em seu arquivoGemfile), que vai forçar o RuboCop a seguir as convenções e boas práticas definidas pela comunidade Rails.

Por padrão quando executado, o RuboCop procura por um arquivo.rubocop.yml no diretório atual, logo depois em seu home path (~/.rubocop.yml), e em último caso vai usar as configurações padrões. Mais detalhes sobre a configuração do Rubocop podem ser encontradas na documentação oficial.

Se você deseja criar seu próprio arquivo de configuração, o que é recomendável, um bom ponto de partida é usar o arquivo disponível no repositório do Rubocop como referência. Você pode revisar regra por regra e configurar o que melhor funciona para você. Apenas lembre-se de verificar a disponibilidade da regra para a versão do RuboCop que você esteja usando.

Mantenha em mente que as regras pertencentes ao agrupamento Style são configuráveis e opcionais. Uma boa recomendação é que essas regras sejam discutidas e definidas com toda a equipe, e não somente por uma pessoa.

É bom mencionar que você pode escrever suas próprias cops, chamadas Custom Cops. Com elas, você pode definir suas próprias regras e práticas para garantir que elas serão seguidas. Você pode encontrar mais informações sobre como criar uma Custom Cop na documentação.

Uso

Para usar o RuboCop você só precisa navegar até o diretório onde deseja rodar o linter e executar:

$ rubocop

Você pode especificar um arquivo/diretório:

$ rubocop lib/file.rb

Também é possível especificar uma lista de arquivos e diretórios:

$ rubocop app/ spec/ lib/file.rb

Após rodar o RuboCop, você deve obter uma saída com as possíveis ofensas, algo como:

Offenses:

test.rb:1:1: C: Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.
def badName
^
test.rb:1:5: C: Naming/MethodName: Use snake_case for method names.
def badName
    ^^^^^^^
test.rb:2:3: C: Style/GuardClause: Use a guard clause instead of wrapping the code inside a conditional expression.
  if something
  ^^
test.rb:2:3: C: Style/IfUnlessModifier: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
  if something
  ^^
test.rb:4:5: W: Layout/EndAlignment: end at 4, 4 is not aligned with if at 2, 2.
    end
    ^^^

1 file inspected, 5 offenses detected

Autocorreção

Uma ótima funcionalidade do RuboCop é a autocorreção. Essa opção corrige automaticamente todas as possíveis ofensas no seu código, baseando-se nas regras definidas. Em nosso caso, usamos o argumento -a para corrigir as ofensas consideradas seguras de serem corrigidas, mas você pode ser mais otimistas e usar o argumento-A para corrigir todas as ofensas possíveis (incluindo as que talvez a correção não seja tão segura), mas você precisa usa-lo com cautela.

Para usa-la você precisa rodar o RuboCop com o argumento de autocorreção:

$ rubocop --auto-correct
# ou
$ rubocop -a

Você pode verificar todos os argumentos aceitos pelo RuboCop usando --help:

$ rubocop --help

Apenas para propósitos de lincagem, você pode checar a documentação para saber mais a respeito da funcionalidade de autocorreção.

Integrando com outras ferramentas

O RuboCop Integra-se com muitas outras ferramentas. Você pode integra-lo no seu editor de código para roda-lo toda vez que você salvar um arquivo, e assim obter uma resposta imediata

Para uma lista de editores de códigos suportados, você pode verificar esta página na documentação, e caso o seu favorito não esteja listado, é uma ótima oportunidade para contribuir com o RuboCop implementando uma integração.

Outra ótima integração é criar um Git Hook para rodar o RuboCop após cada commit. Você também pode configurar o RuboCop para ser executado em seu serviço de Integração Continua (CI), como GitHub Actions, para ter insights após cada interação com um Pull Request. Em todos os casos, você pode encontrar mais detalhes na documentação.

Você tem algum caso de uso legal para compartilhar? Sinta-se a vontade para me contatar via Twitter ou use a sessão de comentários abaixo.

Espero que você tenha gostado do conteúdo, e obrigado por ler.

GitHub CLI: PRs, Issues e outros conceitos do GitHub direto no terminal

Gustavo Araujo — Sun, 10 Jan 2021 05:14:23 +0000

O que é?

GitHub CLI (Command Line Interface), como o próprio nome sugere, é o GitHub via linha de comando. Com essa ferramenta é possível trazer pull requests, issues e outros conceitos do GitHub para dentro do terminal.

Como sugere o repositório oficial, a CLI do GitHub está disponível para repositórios hospedados em GitHub.com e GitHub Enterprise Server 2.20+, e pode ser instalado em MacOS, Windows e Linux.

Vale a penar usar?

É uma pergunta bastante relativa, que pode ser respondida levantando dois pontos:

Você é um amante do Terminal?
Você já usa o git via CLI?

Se a resposta para ambos for sim, talvez vale a pena dar uma olhada mais a fundo.

Com a ferramenta, você consegue abrir um Pull Request pelo mesmo terminal que faz seus commits, o que nos poupa bastante tempo, simples e rápido.

Como instalar

Como não é bem o foco aqui, vou deixar a recomendação de consultar a própria documentação.

Após instalar, execute o seguinte comando para testar o funcionamento e já verificar todos os comandos:

$ gh --help

Lembrando que, gh é o próprio binário, não se trata de um alias 🙂.

Passos iniciais

O primeiro passo após instalar é autenticar com sua conta do GitHub, para isso basta executar o comando:

$ gh auth login

Existem duas formas de login:

Via token, que pode ser gerado no GitHub
Login no navegador

Por questões de praticidade, recomendo a segunda opção. Após autenticado, você pode verificar o status com o comando:

$ gh auth status

Feito isso, caso queira você já pode configurar o seu editor de texto favorito para editar as mensagens de Pull Requests:

$ gh config set editor <editor>

Lembrando que, caso não seja atribuído nenhum editor utilizando o comando acima, o gh assumirá o padrão definido na variável de ambiente $EDITOR (No MacOS e no Linux o editor padrão é o Nano, no Windows Notepad).

Mais detalhes sobre o comando gh config podem ser encontrados na documentação oficial.

Hands-on - O que é possível fazer?

Abaixo temos algumas das coisas interessantes que essa ferramenta nos permite fazer.

Pull Requests

Abrir um Pull Request:
```
$ gh pr create
```
Algum dos parâmetros interessantes que temos aqui:
- Com o parâmetro -B podemos especificar o base branch, isto é, para qual branch essas alterações serão enviadas após o merge:
```
$ gh pr create -B main
```
- Com o parâmetro -d podemos especificar que se trata de um Draft Pull Request:
```
$ gh pr create -d
```
Fechar/reabrir um Pull Request:
```
$ gh pr close/reopen
```
Mergear um Pull Request:
```
$ gh pr merge
```
Listar Pull Requests:
```
$ gh pr list
```
Ver o diff de um Pull Request:
```
$ gh pr diff
```
Revisar um Pull Request:
```
$ gh pr review
```
Verificar os status checks de um Pull Request aberto, como o CI:
```
$ gh pr checks
```
Verificar seu status de Pull Requests:
```
$ gh pr status
```

Issues

Criar uma Issue:
```
$ gh issue create
```
Fechar/reabrir uma Issue:
```
$ gh issue close/reopen
```
Listar Issues:
```
$ gh issue list
```
Ver uma Issue:
```
$ gh issue view
```
Verificar seu status de Issues:
```
$ gh issue status
```

Considerações finais

Com certeza é uma ferramenta sensacional, que, se bem usada nos poupa bastante tempo. E você, o que achou? Já usa a ferramenta? Me conta nos comentários 🙂.

Caso tenham dúvidas, sintam-se a vontade para me contatar via Twitter 😉