1. Este site usa cookies. Ao continuar a usar este site está a concordar com o nosso uso de cookies. Saber Mais.

Cuidados com o código (nomes, convenções, etc)

Discussão em 'Programação' iniciada por CrazyBomber, 26 de Março de 2008. (Respostas: 23; Visualizações: 1528)

?

Tem cuidado com os codigos de progração

  1. Sim

    29 vote(s)
    69,0%
  2. Não

    4 vote(s)
    9,5%
  3. ás vezes

    9 vote(s)
    21,4%
  1. CrazyBomber

    CrazyBomber Power Member

    Venho inquirir os programadores do fórum se, sendo estudantes ou profissionais, costumam ter cuidado com o código que escrevem. Isto para qualquer linguagem (mas com especial atenção a bases de dados - nomes de tabelas, colunas, etc), claro.

    Comentários, nomes de funções e variáveis, CamelCase, lowerCamelCase, ou outra, etc.
    Na vossa experiência, é importante dar a devida atenção a estes "pequenos" pormenores?

    Como comentam o código? Podem dar algum(s) exemplo(s)?

    Se trabalham numa empresa, essa tem algum "manual de convenções", que todos são incentivados a usar, ou é "como cada um achar melhor"?

    Sou estudante de MEI (muito perto de terminar), e nos últimos 2 anos do curso tenho tido vários professores a realçar este assunto. Gostava de saber como é a realidade, sobre este assunto, em Portugal...

    Obrigado a todos pela (futura) participação :)
     
  2. flaviorodrigues

    flaviorodrigues Power Member

    costumo alinhar o codigo mas tambem programo em asp.net e a aplicacao ja o faz!

    Comento sempre as primeiras linhas e ponho o que falta fazer ou ideias exemplo:

    ' ************************************************
    ' Acabar validacao x
    ' ************************************************

    dou nomes as variaveis em condicoes para saber o que e mais tarde, as tabelas igual, nao faço como ja vi projectos do genero:

    Variaveis: a,b,c,d,e
    Campos na tabela: Camp1,camp2,camp3

    eu prefiro usar:
    Variaveis: erro, validacao, nome, idade, morada
    Campos na tabela: ID, nome, password, morada, idade...
     
  3. ffar

    ffar Power Member

    Boas,

    Na empresa onde trabalho existem duas situações:

    1- Nos projectos em parceria com outras empresas existe sempre um "Software Coding Standard" onde as regras e numenclatura a utilizar está bem definida.

    2- Nos projectos internos, se este documento não existir, a equipa de desenvolvimento costuma-se reunir antes e durante o desenvolvimento de modo a acertar estes detalhes.

    Para a legibilidade, debug, manutenção, facilidade de outras pessoas agarrarem no código mais tarde é muitissimo importante existirem este tipo de regras. Se eu fosse dono de uma empresa obrigava todos a seguir um standard.

    Por outro lado há um reverso da medalha, se quiseres que o código seja dependente de ti, ou seja, para lhe mexerem têm de vir ter contigo então não há nada como usar o a, b, c, d, etc como o flaviorodrigues exemplificou.
     
  4. slack_guy

    slack_guy Power Member

  5. Armadillo

    Armadillo Folding Member

    dicas muito rapidas:
    começar o nome das vars pela 1ª letra do seu tipo de dados (nao faço mas devia... shame on me)

    Código:
    dim i_variavelQualquer as integer
    
    comentarios alinhados (dá um jeitaço para ler os comentarios (chego a fazer autenticas redacçoes do codigo com este metodo) :D

    Código:
    [FONT=Courier New]
    while (false !== ($filename = readdir($dh)))         //enquanto nao chegar a ele mesmo, ou seja, ao fim
    {    $posIniConta = strpos( $filename, $prefixo);    //verifica se existe o prefixo enviado no nome de ficheiro.
        if ($posIniConta===0):                           //se tiver o prefixo "Utiliz" 
            $files[] = $filename;                        //insere no vector para posterior processamento
        endif;
    [/FONT]
     
  6. Baderous

    Baderous Banido

    O código deve ser bem comentado bem como as variáveis e funções devem ter nomes representativos da sua função para favorecer a reutilização dos módulos criados pelo programador. Aliás, a documentação de um projecto é um dos pontos mais importantes da Engenharia de Software.
     
  7. Armadillo

    Armadillo Folding Member

  8. The_True_Eue

    The_True_Eue Power Member

    Chama-se Hungarian notation. Também há quem lhe chame Microsoft notation. Mas não tenhas "shame on you" por não o fazeres. É desaconselhável. Por várias razões:
    1. Não adiciona expressividade nenhuma, apesar do que parece. Se necessitas deste tipo de coisas para te lembrares dos tipos das variáveis, das duas, uma: ou os teus nomes são extremamente parecidos, o que geralmente indica mau design; ou tens demasiadas variáveis, o que geralmente indica scopes (funções, ou ciclos) demasiado longos.
    2. Diminui a legibilidade do código. Lê este artigo que exagera um bocado nisso, mas é um bom exemplo. Já agora, o livro C Elements of Style do mesmo autor (Steve Oualline), apesar de bastante antigo, ensina várias práticas para escrever código de fácil compreensão e manutenção.
    3. Obriga a teclar mais (sim, é só uma letra, eu sei, mas não resisti a dizer isto...)
    4. Não existe razão 4. (piada geek com referência a null-terminated strings)
    ---
    Eu sigo regras que eu próprio "coleccionei" de várias fontes ao longo dos anos. Por vezes penso que são demasiadas e demasiado restritivas, mas já me habituei a seguí-las à risca e não consigo fazê-lo de outra forma. Aqui vai uma descrição pormenorizada(íssima)...
    • Uso Allman indenting.
    • Uso tabs de comprimento 4. Tabs mesmo, não é espaços.
    • Uso camelCase para váriaveis locais, campos privados de classes, parâmetros de funções e outras coisas que não são visíveis externamente.
    • Uso PascalCase para tudo o que sejam membros públicos de classes, classes, namespaces, e tudo o que seja visível do exterior.
    • Dou sempre nomes em inglês às coisas, e sem erros ortográficos. Tenho sempre um dicionário à mão.
    • Não abrevio praticamente nada.
    • Dou nomes bastante descritivos. Geralmente percebe-se logo o que faz um método, propriedade, ou parâmetro só pelo nome.
    • Nos nomes das variáveis locais, costumo ser um bocado liberal na nomenclatura, geralmente quando têm pouco valor semântico, e uma vez ou outra lá aparece um a ou um b. Mesmo assim escolho a primeira letra do que essa variável representa.
    • Não uso Hungarian notation, ou qualquer outra forma de prefixação.
    • Dou nomes plurais a collecções e singulares a átomos.
    • Tento sempre ser o mais expressivo possível na escrita de instruções.
    • Só coloco mais que uma instrução por linha quando estas estão extremamente relaccionadas. Mas na maior parte das vezes, acabo por pegar nesse código e pô-lo numa função ou método. Se são assim tão relaccionadas justificam ser uma unidade.
    • Evito escrever funções com mais de 10-15 linhas. Quando chego às 20, geralmente noto que estou a fazer duas ou três coisas nessa função, e por isso deviam ser duas ou três funções. "Do one thing and do it well." - Unix philosophy
    • Declaro variáveis locais o mais tarde possível, i.e., mais próximo de onde são usadas, para ajudar a perceber o seu objectivo. Em C, que remédio, ponho tudo no ínicio...:(
    • Comento todas as entidades visíveis do exterior com descrições da sua funcionalidade, conteúdo, valor de retorno, excepções, parâmetros, etc. Se possível uso comentários com formatação especial para geração do documentação como XML comments em C#, JavaDoc em Java, Haddock em Haskell, etc.
    • Comento as entidades não visíveis do exterior que não sejam triviais.
    • Em código pouco expressivo, geralmente comento todas ou quase todas as linhas.
    • Por vezes, apesar de achar que o deva fazer mais vezes, incluo pré-condições, pós-condições e invariantes nos comentários.
    • Em C, utilizo quase assert() pelo menos uma vez em quase todas as funções, para ajudar a fazer debugging.
    • Uso sempre espaços antes e depois dos operadores binários, sem espaços em torno dos parêntesis das funções, espaços depois das vírgulas.
    • Escrevo as coisas de modo a que sejam o mais naturais possível, p.e., em vez de if(!strcmp(a, b)) para ver se a e b são iguais, escrevo if(strcmp(a,b) == 0). São mais alguns caracteres para teclar, mas "not string compare" não soa nada a igualdade.
    Acho que depois disto é óbvio que para mim é muito importante ser-se consistente na escrita de código, e escrever código que seja o mais expressivo possível. Os comentários ajudam sempre, e quanto mais descritivos, melhor.
     
  9. Armadillo

    Armadillo Folding Member

    defesa de honra: normas da casa! :smiliel:
    mas que dá jeito em algumas situações, dá!

    é tudo uma questao de estilos (e tambem depende das ferramentas que usas): como eu nao comecei a programar com esse estilo, ainda hoje nao uso (mesmo devendo), mas ningeum liga a isso (no caso da HN). O mais importante mesmo é haver documentação do codigo e bons comentarios (atençao que sao coisas diferentes)

    cumprimentos
     
  10. The_True_Eue

    The_True_Eue Power Member

    Gostos não se discutem. E quanto a estilos de programação... Ainda menos. Só queria referir as razões que me levam a não o fazer. Não gosto nada de ler código escrito em MS notation. Mas não é dos piores casos...
     
  11. CrazyBomber

    CrazyBomber Power Member

    Por acaso também não sou fã da hungarian notation...
    Obrigado pelos comentários, até agora :)
     
  12. alfinete

    alfinete Power Member

    eu costumo fazer assim em c#


    costumo dividir o code behind em varias regioies e zonas dentro das regioes
    Código:
    
    #region eventos
    #endregion
    
    
    #region metodos
    
    /*****************************************************************/
    /***********************zona gravação*******************************/
    /*****************************************************************/
    
    /*gravaregx*/
    private void grava_regx()
    {}
    
    /*gravaregy*/
    private void grava_regy()
    {}
    
    
    
    /*****************************************************************/
    /***********************zona validação*******************************/
    /*****************************************************************/
    
    /************ validação txtbox****************************/
    
    /* valida txt dados*/
    private bool vtxtdados()
    {
    }
    
    /* valida txt dados2*/
    private bool vtxtdados2()
    {
    } 
    
    
    /************ validação drop downlists****************************/
    
    /* valida ddl dados*/
    private bool vddldados()
    {
    }
    
    /* valida ddl dados2*/
    private bool vddldados2()
     {
     } 
    
    
     /************ validações gerais****************************/
     
     /* valida datas*/
     private bool vdata()
     {
     }
     
     /* valida formataçãodata */
     private bool vstringdata()
      {
      } 
    
    /*****************************************************************/
     /***********************zona upload*******************************/
    /*****************************************************************/
    
    
    private void uploadsx()
    {
    }
    
    
    private void uploadsy()
    {
    }#endregion
    
    
    

    como vez pata validações ponho "v" antes do resto do nome
    para gravações "grava"
    para upload "upload"


    no caso de ter uma classe que ira ser chamada num codebehind de um aspx

    uso nomes de variaveis privadas tdas com letra minuscula
    variaveis publicas com primeira letra maiuscula

    do tipo

    Código:
    
    private string teste="";
    
    public string Teste;
    
    
    quanto ao resto nas formatções de momenclarura nestas classes são iguais

    é mais ou menos assim que fasso
     
  13. bikefire

    bikefire Banido

    Tem cuidado nos códigos de programação?

    a pergunta dix tudo
    exemplos:

    para por o nome dum componente deixam ficar como já tá "textbox1" ou mudam o nome "txtnome" ?

    outro exemplo

    if xxx= yyyy then
    msgbox ("aaa")

    end if

    deixei um espaço entre end if e msgbox
    voces preocupam-se com isso
     
  14. renafi

    renafi Power Member

    Depende da complexidade do programa. Mas em 90% dos casos, claro que sim. Senão depois já não sabes a quantas andas.
     
  15. Tyran

    Tyran Power Member

    Sim tenho :P

    Só um reparo:

    Às vezes

    julgo que tens o acento mal :P
     
  16. Isepiano

    Isepiano Power Member

    Sim tenho, a organização na programação é essencial e eu que programo em Java tento sempre colocar comentários para saber o quê que faz determinado código sem ter que olhar para ele e pensar para que será. E quando são programas feitos por vários programadores dão muito muito jeito os comentários. Mas penso que o facto de deixar espaços como esse não é assim tão relevante porque utilizo NetBeans em que a versão 6 põe tudo às cores para se distinguir tudo.

    Cumps
     
  17. skorzen

    skorzen Power Member

    Sim, sempre. Apesar de saber programar mal, tenho sempre cuidado. Caso contrário, nem sequer me conseguía orientar.
     
  18. Eu tento ter sempre o máximo de cuidado, de forma a deixar tudo legível e dando nomes explícitos aos identificadores.
     
  19. DarkWolfXP

    DarkWolfXP Power Member

    Eu tento sempre definir as variaveis de acordo com as suas funções..(á quem n faça :p)
    Gosto também de organizar o codigo de que fique esteticamente agradavel e fácil de compreender...
    Cumps
     

Partilhar esta Página