O bom filho a casa retorna: Visitando seu código antigo

Texto Otávio Albuquerque
Edição Marília de Sousa e Elis Ionara
Ilustração Luciana Adrião

Imagine a seguinte situação: Você está na sua escola, no ensino fundamental, especificamente no 9º ano, estudando equações de segundo grau cujo assunto é a famigerada fórmula de Bhaskara. Na época, isso não foi um problema, mas era chato só decorar a bendita fórmula e outras coisinhas aparentemente inúteis. Anos depois, você, agora no ensino médio, se encontra numa situação onde precisa calcular a máxima ou mínima de uma função do segundo grau. Seu professor diz: “É tranquilo, galerinha! Só relembrar do fundamental!” E você lembra de ter visto como calcular, mas saber que é bom, nada. A primeira solução que você pensa ao chegar em casa é revisitar seu caderno de anotações do fundamental, apenas para se deparar com um caderno totalmente confuso e ininteligível. Fica apenas a sensação de que não parece que foi você que escreveu aquilo, ainda mais porque faz tanto tempo. Mas esse não é o problema, o problema é ter a dificuldade de consumir algo que você produziu pra si mesmo, e não devia ser tão difícil assim, pois soluções como uma descrição melhor ou apenas dar nome ao passo-a-passo já resolveria.

E quem diria que isso acontece aos montes em programação? É super comum fazer um código simples, para aprender algo ou apenas para resolver um bug, e deixar ele solto, totalmente fora de contexto. Quando se acaba precisando desse pedacinho de código para algo que você está fazendo atualmente, você acaba ficando um tempão preso tentando entender onde que você colocou o código, por que que ele está ali, o que ele faz e o que é preciso para implementá-lo no seu projeto atual. Tarefa que poderia ser bem mais simples apenas tendo o hábito de boas práticas de programação.

Cada um no seu cada qual

A primeira coisa a se perceber é quando seu código está à deriva, solto em um emaranhado de outras linhas de código que aparentemente não tem nada a ver com o que você escreveu. Isso dificulta a localizar o seu bloco de código num mar de informação. Para isso, as extensions são as suas amigas.

O poder de organização das extensions

Primeiramente, extensions são formas de, como o nome elucida, estender seu código com outros atributos, métodos, protocolos, entre outros. Assim, extensions evitam arquivos com muitas linhas de código, te permitindo organizar partes de uma mesma entidade de acordo com a suas responsabilidades. Como exemplo, imagine uma ViewController que também funciona como DataSource e Delegate de uma CollectionView, você poderia fazer da forma bagunçada, que é jogar tudo dentro da controller, por exemplo: Cada função dessas possui um código grande dentro, isso sem contar com outra funções que podem existir dentro do código além das principais citadas acima. dessa forma, é melhor separar a as funções da classe ViewController por extensões, com cada extensão tendo as suas responsabilidades (inclusive é legal ter a responsabilidade escrita no nome do arquivo.

// ViewController.swift
class ViewController: UIViewController, UICollectionViewDataSource,
UICollectionViewDelegate {
 override func viewDidLoad() {
 // codigo 1
 }
 func collectionView(_ collectionView: UICollectionView,
numberOfItemsInSection section: Int) -> Int {
 // codigo 2
 }

 func collectionView(_ collectionView: UICollectionView, cellForItemAt
indexPath: IndexPath) -> UICollectionViewCell {
 // codigo 3
}
 func collectionView(_ collectionView: UICollectionView, didSelectItemAt
indexPath: IndexPath) {
 // codigo 4
 }
}

Dessa forma, fica muito mais simples encontrar trechos de código que você quer, sem ter que navegar por um arquivo de mais de 300 linhas, que possui várias responsabilidades diferentes.

Cada função dessas possui um código grande dentro, isso sem contar com outra funções que podem existir dentro do código além das principais citadas acima. dessa forma, é melhor separar xilidades (inclusive é legal ter a responsabilidade escrita no nome do arquivo):

// ViewController.swift
class ViewController: UIViewController {
 override func viewDidLoad() {
 // codigo 1
 }
}

// ViewControllerCollectionViewExtension.swift
extension ViewController: UICollectionViewDataSource,
UICollectionViewDelegate {

 func collectionView(_ collectionView: UICollectionView,
numberOfItemsInSection section: Int) -> Int {
 // codigo 2
 }

 func collectionView(_ collectionView: UICollectionView, cellForItemAt
indexPath: IndexPath) -> UICollectionViewCell {
 // codigo 3
}
 func collectionView(_ collectionView: UICollectionView, didSelectItemAt
indexPath: IndexPath) {
 // codigo 4
 }
}

Dessa forma, fica muito mais simples encontrar trechos de código que você quer, sem ter que navegar por um arquivo de mais de 300 linhas, que possui várias responsabilidades diferentes.

Pessoalmente, vejo debates muito grandes sobre comentários em códigos. Alguns acreditam que não ajudam em nada, deixam o visual mais poluído já que o seu uso, em maioria, é para remover códigos do arquivo momentaneamente. Outras pessoas adoram comentários pela mesma função descrita acima, junto com a possibilidade de usar o próprio arquivo como documentação, e é nessas duas possibilidades que comentários brilham na documentação de um código.

Uma das formas mais interessante de usar comentários são com Tags. Tags são nomes nos comentários que são marcados com Highlights no Xcode, chamando sua atenção brevemente para aquele trecho de código. Existem três principais tipos: MARK, TODO e FIXME. Mark, como o nome diz, apenas marca uma mensagem nos comentários, e é geralmente usado para explicar ou “etiquetar” o trecho de código, como no exemplo abaixo:

class ViewController: UIViewController {
// MARK: - Finalizar viewDidLoad()
 override func viewDidLoad() {
 // codigo 1
 }
}

class ViewController: UIViewController {
// TODO: - Retirar as anchors do
ViewDidLoad
 override func viewDidLoad() {
 // codigo 1
 }
}

TODO, ou To Do, é a marcação para lembrar coisas que você tem que fazer naquele trecho, como refatoração, complemento, finalização, entre outros.

class ViewController: UIViewController {
// FIXME: - Função chamada mais de duas
vezes
 override func viewDidLoad() {
 // codigo 1
 }
}

FIXME, ou Fix me, é a marcação para resolver bugs no código e refatorar parte feitas na pressa.