Tag Archive | estilo

Feijão por cima do arroz ou o inverso?

O arroz sempre é seco, enquanto o feijão costuma vir acompanhado de seu próprio molho (que inclusive é a razão de termos a receita do caldo de feijão). No prato, nunca colocamos o molho por baixo, por que deveria ser diferente quando misturamos feijão com arroz?

OFF-TOPIC

Nada nesse blog foi postado desde o início do ano, pois, mais uma vez, estou preparando posts longos, explicativos e que exigem um pouco mais de pesquisa que o normal.

Espaço: o separador natural de palavras

Antes do lançamento da Allegro 5, tinha uma página na wiki deles com uma discussão interessante sobre estilo de API. Tinha uma frase de lá que eu não conseguia esquecer, mas por várias vezes já quis referenciar durante discussões e eu não conseguia reencontrar. Recentemente, acabei reencontrando tal frase e resolvi fazer um post dedicado aos momentos em que eu não usei essa referência. Isso mesmo, eu me rebaixei a fazer um post de dois parágrafos, onde um deles nem é de minha autoria.

Graças ao sublinhado, tudo fica mais legível. “Por que?”, você pergunta. Bem, quando somos crianças e aprendemos a ler, nossos padrões cerebrais se adaptam para reconhecer o espaço (ou o sublinhado, que é graficamente similar) mais facilmente como um separador de palavras.

— tradução livre de trecho encontrando na wiki do Allegro

Documentação: no arquivo de implementação ou no arquivo de interface?

C++ é uma das linguagens com um modelo frágil na hora de importar declarações, pois a linguagem não define como importar declarações de nomes e a única técnica que nos resta é mágica de pré-processamento através de include e suas respectivas define guards, dentre algumas outras curiosidades. Mas o objetivo desse post não é discutir essa fragilidade. Além dessa fragilidade não-especificada, mas bem conhecida (pesquise por propostas para módulos em C++ se quiser mais informações), há o interessante padrão de separar abstrações em arquivos de implementação e arquivos de interface. Aliado a técnica de documentar as abstrações através de comentários (dessa vez sua pesquisa vai ser sobre Doxygen), no próprio código-fonte, surge a pergunta: A documentação deve ser feita no arquivo de implementação ou no arquivo de interface?

Eu sempre preferi colocar a documentação no arquivo de interface, pois tenho essa ideia estranha de que um dia haverão IDEs bem completas para C++ que serão capazes de mostrar a documentação para um nome baseado no conteúdo dos arquivos incluídos através da diretriz “#include” e isso (detecção automática da documentação) não funcionaria muito bem caso a documentação fosse feita nos arquivos de implementação, pois ela iria se perder. Claro que considero esse argumento um gosto pessoal, pois há preocupações do mundo real a considerar, como, por exemplo, o tamanho de um pacote de desenvolvimento de uma nova biblioteca. Mas recentemente eu estava brincando com a boost e lembrei que há muitas bibliotecas header-only, que não possuem arquivos de implementação e ao mesmo tempo lembrei da questão antiga abordada nesse post. Bom, esse seria um argumento definitivo para optar por incluir a documentação nos arquivos de interface, pois essa abordagem funciona sempre.

Tabulação vs espaços

Quando eu comecei a programar, descobri a indentação e passei a achar interessante o uso do caractere de tabulação para fazer a indentação do código. Hoje eu utilizo espaços e resolvi escrever esse post para partilhar alguns fatos sobres esses dois “concorrentes”.

É natural pensar que caractere invisível da tecla tab e o conceito de identação foram feitos um para o outro, afinal o tab mapeia o conceito de identação muito bem. Você quer um nível de identação, tab (1x). Você quer dois níveis de identação, tab (2x). O mesmo não ocorre com espaço. Você quer um nível de indentação, espaço (2x, 4x ou 8x). Você quer dois níveis de identação, espaço (4x, 8x ou 16x). Como se não bastasse, grande parte dos editores de texto permite personalizar o tamanho de espaço deixado pelo tab. Assim, o código se adapta ao usuário e acabam as discussões sobre o quanto é uma boa quantia de espaço.

Entretanto, há uma tarefa para o qual o caractere de tabulação simplesmente não funciona. Essa tarefa é o alinhamento e ela É comum em programação. Se você por acaso não acha que essa é uma tarefa comum, é porque propositalmente a evita, ou talvez porque só programou tantas linhas de código quanto a participante SaraJo, pelo menos publicamente, dessa discussão feminista desnecessária no projeto libuv. O código e a imagem a seguir tentam demonstrar o que é espaço para identação e espaço para alinhamento:

indent

Até hoje eu não vi um único editor esperto o suficiente para ser capaz de fazer a indentação usando caracteres de tabulação e espaços para alinhamento. Sempre é “espaços ou tabs, escolha um”.

Além do problema do alinhamento, outra desvantagem do tab é justamente o que apresentei anteriormente como uma vantagem, que é uma visão personalizada do código para cada usuário. O problema ocorre pelo fato de muitas das convenções de código adotar um limite no número de caracteres por linha (normalmente para 80 ou 100), mas quando cada programador do time configura seu editor para mostrar um número diferente de espaços para o caractere de tabulação, fica, no mínimo, complicado obedecer essa regra.

Agora vamos deixar os fatos de lados e começar a enxergar outros aspectos:

EDIT (2016/06/01):

Encontrei uma ótima referência ao assunto graças ao Magnun: https://www.emacswiki.org/emacs/TabsAreEvil (um pouco irônico ele ter mandado link da wiki do Emacs já que ele é usuário de vim)

Imagem da página 2016-06-01 - 14.44.27

EDIT (2016/07/15):

Algumas estatísticas sobre tabs e espaços do GitHub.

%d blogueiros gostam disto: