Jump to content

Discussão - Coding Ways


Localhost
 Share

Recommended Posts

Não tinha mais nada para fazer então lembrei-me de criar um tópico para discutir aqui alguns pormenores que cada um usa quando está a codar em C ou em C++, pormenores como identação, nomes que dão às variáveis, maneira como criam os headers das funções, etc.

Não quero que me dêem uma resposta a cada elemento da (pequena) lista que criei, quero que discutam e que tragam novas ideias ao tópico.

Btw, também trago aqui algo para o tópico que é uma maneira de declarar variáveis que eu próprio já usei mas que depois desisti que é Hungarian Notation, onde existem opiniões divergentes em relação à mesma, já agora deixo aqui algumas opiniões de nomes sonantes sobre a mesma:

    * Linus Torvalds (against systems Hungarian):

          "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer."[3']

    * Steve McConnell (for Hungarian):

          "Although the Hungarian naming convention is no longer in widespread use, the basic idea of standardizing on terse, precise abbreviations continues to have value. ... Standardized prefixes allow you to check types accurately when you're using abstract data types that your compiler can't necessarily check."[4]

    * Bjarne Stroustrup (against systems Hungarian for C++):

          "No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming—both of which emphasize selection of operations based on the type an arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction."[5]

    * Joel Spolsky (for apps Hungarian):

          "If you read Simonyi’s paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that us meant “unsafe string” and s meant “safe string.” They’re both of type string. The compiler won’t help you if you assign one to the other and Intellisense won’t tell you bupkis. But they are semantically different; they need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you’re lucky. (...) There’s still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug, and maintain, and, most importantly, it makes wrong code look wrong."[6]

Algo mais para acrescentar ao tópico, o tão falado goto, vou deixar mais algumas opiniões:

I think goto's are fine, and they are often more readable than large

amounts of indentation. That's _especially_ true if the code flow isn't

actually naturally indented (in this case it is, so I don't think using

goto is in any way _clearer_ than not, but in general goto's can be quite

good for readability).

Of course, in stupid languages like Pascal, where labels cannot be

descriptive, goto's can be bad. But that's not the fault of the goto,

that's the braindamage of the language designer.

http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

here since 2009

Link to comment
Share on other sites

Bem, existe para aí um standart quanto a isso. As regras que cumpro mais são

Constantes: LETRAMAIUSCULA

Classes/Estruturas: PrimeirasLetrasMaiusculas

Funcoes: primeiraLetraMinuscula

Variaveis: tudoemminusculas

ifs SEMPRE com chavetas

Ex:

if (condicao) {doIt();}

em vez de

if (condicao) doIt();

Quanto à identação, depende do bloco de código e da forma como o estou a organizar... se estou com pressa a programar ou não... sei lá, acho que não cumpro grandes regras nisso.. Vou identando conforme necessário.

EDIT: Quanto ao Hungarian Notantion, penso que não seja necessária, mas se por alguma razão for necessário usar numa variável em particular, não vejo porque não. No caso geral penso que seja um bocado abusado.

MIEIC @ FEUP

http://project557.blogspot.com/ --- Development Blog

Proteja a sua pen: http://lastknight.pt.vu

Link to comment
Share on other sites

ifs SEMPRE com chavetas

Ex:

if (condicao) {doIt();}

em vez de

if (condicao) doIt();

Enquanto "pythonista", eu faria

if (condicao) 
    doIt();

Whitespace is beautiful, man! 🙂

❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Link to comment
Share on other sites

Bem, enquanto programador amador eu gosto muito de ver um código bonito e limpo. E duas coisas essenciais para isso é a indentação e comentar o código (que por acaso até é tido em conta na avaliação de um código na minha disciplina de programação e em muitos outros sitios).

Quando programo em C uso sempre as chavetas nos if's mesmo que sejam apenas uma linha como referido pelo JD557, mas coloco tal como o IceBrain disse pois tona muito mais legível o código. A indentação é por muitos ignorada e fica um código feio, até mesmo ilegível, especialmente em if's encadeados por exemplo. Por sorte a maioria dos IDE's já identa o código de if's, whiles, for's e do whiles, etc, etc.

if (!strcmp(michael_jackson,"cool")) {
    printf("É mentira\n"); }
else {
         printf("Acertou, até o zé cabra é melhor\n");
}

Para alem da indentação, uma linha em branco entre if's ou entre "partes" do código (tipo entre dois cases) fica mais bonito e dá para, quando o código é extenso ficar mais simples localizar algo.

case 1: {  } //Também usar aqui as chavetas mesmo que seja só uma linha

case 2: { 
printf("Linha em branco por cima fica bonita");  }

Para algo mais alargado, quando necessito de variáveis globais e estas são bastantes mas para funcionalidades diferentes costumo usar "blocos de declaração" sempre comentados

//Variáveis para o edit
int nuke, inferno, dust2, italy; //Na parte do Counter Strike
char grimbatol, argentdown; //Na parte do World of Warcraf

//Variaveis auxiliares
int aux,aux2,aux3;

Em relação à notação, normalmente em C coloco um nome de algo relacionado com o tema /programa ou, em código mais extenso uso nomes relacionados com a parte onde é inicialmente inserida a variável. Normalmente para variáveis declaro até as variáveis a meio do código, usando na mesma as linhas em branco e o comentário.

printf("%d\n",aux2);

//Para os ingredientes do bolo
int ovos, farinha, manteiga;

printf("Insira a quantidade de ovos que vai usar\n");
scanf("%d",&ovos);

Por vezes neste exemplo acima, como o scanf está directamente ligado ao printf indento o scanf para ficar um pouco mais à frente do printf e assim guiar-me melhor caso altere o nome das variáveis ou algo que envolva alterar os dois directamente.

Em VB.net (que não tem a ver com o tópico mas que pode ser numa utilização a aplicações CLI) eu uso um pouco a notação hungara em Forms com muitos elementos pois dá uma ajuda quando sabes que tipo de elemento é mas não sabes o nome de cor, então se usares o inicio, neste caso de uma textbox, se usares o "txtb" o VS vai dar a sugestão para o que é e é muito mais rápido de escrever o código.

E muitas outras "mariquices" que gosto no código e até no nome do ficheiro do source.

Link to comment
Share on other sites

Usar chavetas num switch é muito pouco usado, eu até desconhecia que se podia fazer isso.

Na minha opinião deve-se evitar usar chavetas sempre que possível, as chavetas só tornam o código mais ilegível.

Penso que não, é verdade que muitas juntas podem confundir um pouco, mas nesses casos eu costumo também comentar logo a seguir à chaveta a explicar a que pertence. Tem alguns IDE's, tipo o CodeBlocks(?), que fecham a chaveta mal a abres para nao haver problemas com chavetas

Link to comment
Share on other sites

Há quem diga que muitos comentários inline é um code smell, e que é um sinal que o código devia ser refactorado em métodos mais pequenos, nomes mais descritivos, etc.

❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Link to comment
Share on other sites

Acham que se devia implementar um tipo de regras obrigatórias? Ou seja, em vez de se estabelecer um standard que se deveria estabelecer regras ao nível sintáctico. Como por exemplo o Python obrigar à identação.

Na minha opinião cada programador tem o seu "estilo", no entanto temos de admitir que com umas regras bem definidas a nível geral só contribuíria para a qualidade de código, sim porque eu odeio ler o código de outras pessoas.

here since 2009

Link to comment
Share on other sites

Discordo completamente dessa do "estilo". Quem quer programar o seu próprio gestor de contactos pode muito bem programar da forma que quiser e usar as regras que quiser, até pode inventar, é-me indiferente. Agora quando entra numa equipa de trabalho há que seguir regras, porque eu não sou obrigado a entender a porcaria que os outros escrevem só porque eles querem ser rebeldes e ter um estilo próprio. E essas regras resultam da agregação de 2 conjuntos de regras parciais:

- as regras de escrita de código da linguagem em uso (para o caso em que a própria linguagem possui regras, ex: Java) e/ou da framework em questão

- as regras adicionais existentes na equipa de trabalho

Só seguindo uma forma regrada de escrita de código se consegue promover a boa comunicação de ideias entre a equipa (transmitidas via código) e também permite que mais tarde, alguém que não tenha estado envolvido na construção inicial do software, possa adicionar funcionalidades ao mesmo sem grande dificuldade, bastando-lhe para tal conhecer as regras de escrita e olhar para a API (a qual pode ser bastante informativa com o apoio dos comentários).

Quanto à escrita de código C, aprendi as regras do livro do Damas, de um modo geral são essas que utilizo, posso não utilizar um ou outro pormenor porque entretanto aprendi outra forma melhor de escrever decorrente do meu processo de aprendizagem (utilizo o #define CENAS_H em vez de #define _CENAS_H_). Quanto à notação Húngara nunca trabalhei com nenhuma linguagem que a apoiasse ou necessitasse dela, pelo que sou contra a sua utilização nas linguagens que uso, tens aqui um post que fiz há uns tempos sobre o assunto. Os ifs, para mim, só levam chavetas quando têm mais do que 1 instrução e não gosto de ler código cheio de linhas em branco, tenho um colega meu que a cada linha que escreve deixa uma em branco, aquilo é simplesmente nojento de se ler, parece que estou a ver uma nova definição de função a cada linha que leio. A única separação que posso considerar fazer é deixar uma linha em branco entre a definição das variáveis de uma função e o início da lógica da função, mas só no caso em que tenho muitas variáveis, caso contrário não. Já no que toca a comentários, é útil utilizar os diversos tipos de comentários: inline para explicar determinada linha, multi-linha quando a explicação é extensa e ainda os comentários para geração de documentação (com o doxygen) que fornecem informação sobre o que faz uma função e sobre quais os seus parâmetros e resultado.

Link to comment
Share on other sites

Estilos preferidos?

K&R

if (x == y) {
    x++;
    foo();
} else {
    x--;
    bar();
}

Allman

if (x == y) 
{
    x++;
    foo();
} 
else 
{
    x--;
    bar();
}

Whitesmith

if (x == y) 
   {
   x++;
   foo();
   } 
else 
   {
   x--;
   bar();
   }

GNU

if (x == y) 
  {
     x++;
     foo();
  } 
else 
  {
     x--;
     bar();
  }

Horstman

if (x == y) 
{   x++;
    foo();
} 
else 
{   x--;
    bar();
}

Pico

if (x == y) {
    x++;
    foo(); } 
else {
    x--;
    bar(); }

Banner

if (x == y) {
    x++;
    foo(); 
    } 
else {
    x--;
    bar(); 
    }

[me=IceBrain]likes Allman[/me]

❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Link to comment
Share on other sites

[me=IceBrain]likes Allman[/me]

So do I, com duas variantes:

- Se o if contiver apenas uma instrução, dispenso as chavetas, mas a instrução está na linha seguinte e indentada (isto é, não inline);

- Se for uma construção com else, também com apenas uma instrução em cada ramo, e se essas instruções forem atribuições, dou preferência ao operador ternário.

"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Link to comment
Share on other sites

IceBrain: Obrigado por essa excelente contribuição ao tópico.

Bem, o que eu uso é mesmo o K&R, acho que é o que deixa o código mais legível, quando comecei em C realmente usava também o Allman mas depois decidi mudar visto que achava que o meu código ficava, para além de grande, confuso.

Baderous: Também obrigado por esse excelente post.

Concordo com o que disseste, se forem definidas regras ao nível de equipa é muito mais fácil de se trabalhar e de se entender o que cada um faz. No entanto, continuo com a ideia de que se fossem definidas as tais regras a nível sintáctico, mesmo, a qualidade de código melhoraria muito e teríamos uma melhor compreensão de códigos e um melhor entendimento entre programadores. Podes ver isso em outras áreas, como a quimica, por exemplo, usam-se essas tais convenções "obrigatórias" e é muito mais simples de se perceber o que cada coisa quer dizer.

mjamado: Quanto ao primeiro ponto que deste, fazes diferente de mim, uso sempre inlines em if's com uma só instrução, e quando estou com pressa uso inlines mesmo com if's com mais do que uma instrução, mas neste campo admito que já se torna exagero e que não deve ser usado.

pedrix21: Podias explicar melhor essa ideia?

here since 2009

Link to comment
Share on other sites

Bem, o que eu uso é mesmo o K&R, acho que é o que deixa o código mais legível, quando comecei em C realmente usava também o Allman mas depois decidi mudar visto que achava que o meu código ficava, para além de grande, confuso.

Que razões te levam a dizer que o estilo Allman torna o código mais confuso do que o estilo K&R? Não consigo perceber porquê, penso que o Allman deixa o código menos condensado e muito mais fácil de ler.

"What we do for ourselves dies with us. What we do for others and the world, remains and is immortal.", Albert Pine

Blog pessoal : contém alguns puzzles, algoritmos e problemas para se resolver com programação.

Link to comment
Share on other sites

Como já se tem falado cada um um tem o seu próprio estilo de identação, no entanto, na minha opinião, se de cada vez que vais abrir um bloco crias uma nova linha para abrir um bloco e se tiveres vários if's ou blocos seguidos vais acabar por te confundir e até "ficar tonto" com o código e com o que pertecence a quê. Isto é apenas uma opinião e gosto, já programei tanto utilizando o Allman e o K&R (que é o que uso actualmente) e o que gostei mais foi sem dúvida o K&R, daí também ter mudado.

here since 2009

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.