shell-script-pt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [shell-script] Padronização do código


From: Willy Romão
Subject: Re: [shell-script] Padronização do código
Date: Tue, 18 Feb 2014 13:37:36 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Julio,

Muito obrigado pela opinião e pelo conselho.

Vou segui-lo.

Att,

Willy Romão
On 02/18/2014 12:05 PM, Julio C. Neves wrote:
 
É mas depois que escrevi aquilo, fui consultar o material do google-styleguide. Discordo tb de muita coisa que tem lá. Exemplos (não li tudo, ainda estou mais ou menos no meio do artigo):

» Só uso ${Var} para isolar Var ou para expandir parâmetro, como:
# Para não ser interpretado como $Var1, que não está definido
$ Var=5
$ echo Boa ideia é ${Var}1
#  Para receber mais de 9 parâmetros
#+ Passando a b c ... k para o bash corrente
$ set {a..k}
$ echo $11
a1
$ echo {11}
k
Considero qq outro uso de chaves além desses poluição gráfica do script, pq as chaves são muito usadas em Shell para tarefas mais nobres;

» Ele indica usar sublinha (_) no nome de variáveis. Acho desnecessário se usar a 1ª letra de cada palavra em maiúscula. O exemplo que já dei na outra msg, tb se aplica aqui. Para definir uma variável para contar linhas, prefiro ContLin a cont_lin;

» Lá ele coloca:
# Preferred style for 'special' variables:
echo "Positional: $1" "$5" "$3"
Considero isso um absurdo sem nexo nem sentido;

» Ele diz que longas linhas de pipe devem ser no seguinte formato:
# Long commands
command1 \
  | command2 \
  | command3 \
  | command4

Discordo. Prefiro o pipe no final da linha, de forma a não ter de usar contrabarra e poluir a leitura do código:
# Comando longo
comando1 |
    comando2 |
    comando3 |
    comando4

O pior de tudo é que muitos itens (como aquele "Preferred style for 'special' variables" que citei acima) ele simplesmente coloca o que considera certo sem dar nenhuma explicação. Acho que ele confundiu "regras para se escrever um código limpo e confiável" com "minhas preferencias de programação"

Para finalizar, meu conselho é que vc estude bem Shell e crie seu próprio estilo baseado no que vc leu, escrito pelo Aurélio, pelo Paul Armstrong (acho que é esse o nome do gringo) e por mim mas, principalmente, com as suas preferências e, não esqueça, vc está programando para outras pessoas que conhecem Shell, então é muuuuito mais importante ser claro e consistente com o seu estilo que ser babá de pseudo programador. Se o cara não sabe programar, ele não merece mexer em um programa que vc fez com todo o carinho e usando todo o seu know-how.

Abcs,
Julio
@juliobash

Próximos cursos de Shell

Cidade

Local

Período

Curitiba

SoftSell

17-21/02

Rio de Janeiro

EDX

10-14/03

Dou treinamento de shell em qualquer cidade.
Para detalhes, entre em contato por email ou
echo 436233889341364416673541503686485725801923229706P | dc 


Em 18 de fevereiro de 2014 11:25, Willy Romão <address@hidden> escreveu:
 

Julio,

Obrigado por sua opinião.

O que você discorda do Aurélio é basicamente a diferença entre o coding style dele e o do Google.

Willy Romão


On 02/18/2014 11:09 AM, Julio C. Neves wrote:
 
Acho que as dicas do Aurélio são muito boas, apesar de discordar de algumas poucas:

» O sistema só usa variáveis em letras maiúsculas, portanto se vc usar maiúsculas, é grande a possibilidade de criar uma que tenha homônima no sistema (já vi isso ocorrer diversas vezes e é um erro enjoado de localizar). Uso somente a 1ª letra de cada palavra em maiúscula para facilitar o entendimento. É muito mais fácil entender que ContLin é um contador de linhas do que contlin;

» Acho que o uso de colchetes no lugar do test, torna o código mais elegante e mais legível;

» Se vc pensar bem, verá que o operador lógico || equivale a um else sem if. Assim sendo, sou amplamente favorável ao seu uso. Como vc prefere?

if test ! -d dir
then
    mkdir dir
    cd dir
fi

ou

[ -d dir ] || mkdir dir
cd dir

Para uma pessoa ser considerada programador em Shell tem de saber que [..] representa o cmd test e tem de conhecer o uso de operadores básicos como || e &&.

Por falar nisso, acho muito interessante que um cara para programar em python, java, perl, PHP, ... passa um tempão aprendendo a linguagem para se aventurar a escrever or primeiros programas básicos. Em Shell, o cara vai na Internet, procura algo parecido com o que ele precisa e sai ajustando por tentativa e erro até chegar a um resultado parecido com o que ele queria.

A pergunta que mais escuto de meus amigos (todos cobras criadas em Linux) é:
- Julio dá para fazer em Shell ... 
Nem espero a pergunta terminar, vou logo dizendo:
- A pergunta não é essa. A pergunta é: qual é a melhor forma de fazer iso, assim, assim em Shell, pq sempre existirão diversas formas de executar a mesma tarefa.

É muito raro alguém se dedicar a aprender Shell e o usos desses operadores, de expansão de parâmetros e coisas mais rebuscadas é que separam o profissional do curioso.


Abcs,
Julio
@juliobash

Próximos cursos de Shell

Cidade

Local

Período

Curitiba

SoftSell

17-21/02

Rio de Janeiro

EDX

10-14/03

Dou treinamento de shell em qualquer cidade.
Para detalhes, entre em contato por email ou
echo 436233889341364416673541503686485725801923229706P | dc 


Em 18 de fevereiro de 2014 09:38, Willy Romão <address@hidden> escreveu:
 

Pessoal,

Estou começando um projeto relativamente grande em Shell Script (Bash), e fui atrás de documentos sobre a padronização para escrita do código e etc, não achei nada oficial, apenas padrões criados por desenvolvedores e empresas que desenvolvem em Shell Script.
Entre esses padrões que eu encontrei, dois me chamaram muito a atenção e gostaria da opinião de vocês sobre eles, que são:

# Coding Style do Aurelio Jargas
https://github.com/aureliojargas/funcoeszz/wiki/Coding-Style

# Style Shell Guide do Google
https://google-styleguide.googlecode.com/svn/trunk/shell.xml

O que vocês acham deles? Conhecem outros mais completos e melhores fundados do que esses?

Obrigado,

Willy Romão





-- 
Willy Romão

reply via email to

[Prev in Thread] Current Thread [Next in Thread]