BOAS PRÁTICAS DE PROGRAMAÇÃO Semana da FEUP, Porto 27 de Outubro de 2008 #include // main int main()‏ { bool var; if(var == false)‏ // whatever printf(“I hate Hello World's\n”); }

#include // main function int main()‏ { bool var; if(var == false)‏ // whatever printf(“I hate Hello World's\n”); }

#include // main function int main()‏ { bool var; // if var, then whatever if(var == false)‏ printf(“I hate Hello World's\n”); }

// headers #include // main function int main()‏ { bool var = false; // if var, then whatever if(var == false)‏ printf(“I hate Hello World's\n”); }

#include // main int main()‏ { bool var; if(var == false)‏ // whatever printf(“I hate Hello World's\n”); } // hateHelloWorld.cpp // EN: I hate “Hello World” programs // 2008 FEUP // 2008 The boring guy tutoring you // ======================================= // EN: pre-processor // ======================================= // // EN: headers #include // // EN: main function to hate int main()‏ { bool l_condition = false; /** TODO */ if(l_condition == false)‏ printf(“I hate Hello World's\n”); } // ======================================= // == EOF ================================ // =======================================

1. comentar por blocos lógicos 2. evitar comentários desnecessários 3. texto coerente nos comentários 4. separar devidamente as instruções 5. evitar atalhos 6. inicializar variáveis 7. nomes descritivos em variáveis e funções 8. alinhamento do código por blocos

Boas práticas não se limitam a formatação É preciso ganhar disciplina.

// hateHelloWorld.cpp // EN: I hate “Hello World” programs // 2008 FEUP // 2008 The boring guy tutoring you // ======================================= // EN: pre-processor // ======================================= // // EN: headers #include // // EN: main function to hate int main()‏ { bool l_condition = false; /** TODO */ if(false == l_condition)‏ printf(“I hate Hello World's\n”); } // ======================================= // == EOF ================================ // ======================================= // hateHelloWorld.cpp // EN: I hate “Hello World” programs // 2008 FEUP // 2008 The boring guy tutoring you // ======================================= // EN: pre-processor // ======================================= // // EN: headers #include // // EN: main function to hate int main()‏ { bool l_condition = false; /** TODO */ if(l_condition == false)‏ printf(“I hate Hello World's\n”); } // ======================================= // == EOF ================================ // =======================================

Pontos chave  nome do ficheiro no cabeçalho facilita identificação em editores  descrição deve seguir de imediato  identificação da entidade que alberga o projecto é prioritária (a entidade alberga, promove, financia o projecto), ano em que nasceu o ficheiro  identificação dos elementos que alteraram o ficheiro e a data em que o fizeram pela primeira vez  separação do ficheiro por zonas lógicas  prefixo no nome da variável dá pistas sobre a origem  nome da variável é mais descritivo  variável inicializada  zona de código em falta está identificada, torna-se mais fácil detectar zonas incompletas (grep)‏  colocar o valor no lado esquerdo da comparação facilita a identificação potenciais erros // hateHelloWorld.cpp // EN: I hate “Hello World” programs // 2008 FEUP // 2008 The boring guy tutoring you // ======================================= // EN: pre-processor // ======================================= // // EN: headers #include // // EN: main function to hate int main()‏ { bool l_condition = false; /** TODO */ if(false == l_condition)‏ printf(“I hate Hello World's\n”); } // ======================================= // == EOF ================================ // =======================================

Plataforma API de Backend Camada de negócio Camada de apresentação

1. cuidado nas comparações 2. verificação dos resultados das operações 3. consistência na escolha de APIs 4. consistência na escolha de nomes para métodos, funções e variáveis 5. evitar juntar várias operações numa só expressão 6. evitar aglutinar demasiado o código

7. cuidado especial com construtores, destrutores, gestão de memória e excepções 8. quando necessário, gerar API's internas ao projecto, que mascaram o backend e protegem a camada de negócio ao portar para outras plataformas 9. um interface é um contrato e a implementação é (quase) sempre feita à volta do contrato 10. preparar com antecedência os elementos periféricos de que o projecto depende (makefiles?)‏

Desempenho

1. Programadores tendem a tratar o computador como se tivesse recursos infinitos – oops! 2. Armazenamento não é infinito 3. Capacidade de processamento não é infinta 4. Margem de processamento não é infinita 5. Velocidade de transferência não é infinita 6. Volume de transferência não é infinito Problemas

. for(int i = 0; i < 1000; ++ i)‏ { for(int j = 0; j < 1000; ++ j)‏ { for(int k = 0; k < 1000; ++ k)‏ { // algoritmo }. int i = 0; int j = 0; int k = 0; for(i = 0; i < 1000; ++ i)‏ { for(j = 0; j < 1000; ++ j)‏ { for(k = 0; k < 1000; ++ k)‏ { // algoritmo }.

1. Qual o grau de dependência do resto do projecto em relação ao pedaço do bloqueio? 2. É possível dar a volta temporariamente? 3. É importante resolver já ou qualquer decisão agora é irreversível/não viável após o avanço do projecto? Bloqueados?

Ping?