Estilo de codigo.

Para "abobrinhas" use o " Boteco"

Moderadores: andre_luis, 51, guest2003, Renie

Estilo de codigo.

Mensagempor mastk » 15 Abr 2011 08:21

Ola pessoal, estou tendo recentemente um aborrecimento, chamado parceiro:

Duas pessoas estao trabalhando no mesmo codigo, as duas estão praticamente no mesmo nivel, porem, temos um diferença na experiencia em si.

Um da prioridade ao quanto o codigo será legivel, escrevendo o codigo em portugues e nesse estilo:

Código: Selecionar todos
if (SensorAcionada == TRUE){
   RELE_TRAVA = RELE_ACIONADO;
}


O outro tem foco em reduzir o tamanho do codigo e acha bonito o codigo em ingles:

Código: Selecionar todos
if (BIT_PORT_SENSOR)
{
   BIT_PORT_LOCK = 1;
}


Qual das abordagens é mais eficiente segundo vcs?

Um coisa que me irrita nesse tipo de situacao é quando alguem pensa que se tem uma regra absoluta para codificar, e o pior é quando a pessoa pensa assim por anos a fio, deixando de ter a linguagem como ferramente e passa a te-la como o trabalho, e ataca quem seguem algo fora do seus dogmas.
Avatar do usuário
mastk
Dword
 
Mensagens: 4407
Registrado em: 14 Out 2006 20:43

Re: Estilo de codigo.

Mensagempor msamsoniuk » 15 Abr 2011 10:52

eh bem pouco codigo e o codigo gerado, sem duvida, deve ser o mesmo. mas o segundo cara realmente manja de C e usa o dialeto classico K&R, que eh o mais difundido no mundo. sem duvida, a forma que o segundo cara escreve eh universal e o codigo pode ser compreendido no mundo todo, nao apenas por estar em ingles, mas por usar uma notacao classica e padronizada da linguagem.

mastk escreveu:Ola pessoal, estou tendo recentemente um aborrecimento, chamado parceiro:

Duas pessoas estao trabalhando no mesmo codigo, as duas estão praticamente no mesmo nivel, porem, temos um diferença na experiencia em si.

Um da prioridade ao quanto o codigo será legivel, escrevendo o codigo em portugues e nesse estilo:

Código: Selecionar todos
if (SensorAcionada == TRUE){
   RELE_TRAVA = RELE_ACIONADO;
}


O outro tem foco em reduzir o tamanho do codigo e acha bonito o codigo em ingles:

Código: Selecionar todos
if (BIT_PORT_SENSOR)
{
   BIT_PORT_LOCK = 1;
}


Qual das abordagens é mais eficiente segundo vcs?

Um coisa que me irrita nesse tipo de situacao é quando alguem pensa que se tem uma regra absoluta para codificar, e o pior é quando a pessoa pensa assim por anos a fio, deixando de ter a linguagem como ferramente e passa a te-la como o trabalho, e ataca quem seguem algo fora do seus dogmas.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Re: Estilo de codigo.

Mensagempor Jorge_Francisco » 15 Abr 2011 11:21

Eu só faço da segunda maneira, detesto código identados na primeira forma. Esse negócio de chaves em cima é uma m***.

Os compiladores mais recentes tem opção de extender/simplificar as funções ou blocos por meio das chaves . e usando da primeira maneira fica uma m***.

Minha opnião!!

mastk escreveu:Ola pessoal, estou tendo recentemente um aborrecimento, chamado parceiro:

Duas pessoas estao trabalhando no mesmo codigo, as duas estão praticamente no mesmo nivel, porem, temos um diferença na experiencia em si.

Um da prioridade ao quanto o codigo será legivel, escrevendo o codigo em portugues e nesse estilo:

Código: Selecionar todos
if (SensorAcionada == TRUE){
   RELE_TRAVA = RELE_ACIONADO;
}


O outro tem foco em reduzir o tamanho do codigo e acha bonito o codigo em ingles:

Código: Selecionar todos
if (BIT_PORT_SENSOR)
{
   BIT_PORT_LOCK = 1;
}


Qual das abordagens é mais eficiente segundo vcs?

Um coisa que me irrita nesse tipo de situacao é quando alguem pensa que se tem uma regra absoluta para codificar, e o pior é quando a pessoa pensa assim por anos a fio, deixando de ter a linguagem como ferramente e passa a te-la como o trabalho, e ataca quem seguem algo fora do seus dogmas.
Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Mensagempor mastk » 15 Abr 2011 11:22

Entendo, teria publicações com indições sobre essa abordagem?
Avatar do usuário
mastk
Dword
 
Mensagens: 4407
Registrado em: 14 Out 2006 20:43

Mensagempor vtrx » 15 Abr 2011 11:37

Opinião própria.
Se o código é de uso exclusivo,não ha nescessidade de ser 'universal'.
Mas,Variável com nome universal...
Avatar do usuário
vtrx
Dword
 
Mensagens: 2239
Registrado em: 20 Abr 2008 21:01

Mensagempor xultz » 15 Abr 2011 11:39

Mastk, uma coisa que é dificil de explicar prá programadores é que encolher o código-fonte em C não diminui o tamanho dele compilado.
Fazer
if (x=y+3) ...
dá exatamente no mesmo que
x = y+3;
if(x) ...
que dá exatamente no mesmo que
x = y + 3;
if (x == 0) ...

Das três, eu prefiro a última, porque fica mais evidente o que o código deve fazer. Uma vez um livro chamado Practical C e ele mostrava versões compiladas e mostrava que o resultado era idêntico.

Uma outra abordagem interessante eu li no livro do Jack Ganssle, onde ele teoriza que a função mais importante do código-fonte não é ser compilado e funcionar, mas é ser legível e que um humano possa ler e entender seu funcionamento. Gerar um executável dele é mera consequência. E essa cultura deve ser implantada na equipe.
Ele defende que a empresa tenha uma documentação que descreva estética de código e fluxo de trabalho. Por estética de código, compreende-se forma de indentação, nomenclatura de variáveis e funções, estilo de comentários e documentação. Por fluxo de trabalho, procedimento de repositório, revisão de código, testes, etc.
É um assunto complicaod: dá trabalho fazer isso, é impossível chegar um concenso (já tentei criar um padrão de biblioteca de componentes eletrônicos aqui e desisti), mas depois de implantado, dá retorno porque todo mundo fala a mesma língua.
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor msamsoniuk » 15 Abr 2011 11:41

mastk escreveu:Entendo, teria publicações com indições sobre essa abordagem?


http://net.pku.edu.cn/~course/cs101/200 ... nguage.pdf
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor mastk » 15 Abr 2011 11:43

Desculpem, deixei ambiguo, digo eficiencia em codificação, os exemplos que demostrei a saida é a mesma, claro.
Editado pela última vez por mastk em 15 Abr 2011 18:09, em um total de 1 vez.
Avatar do usuário
mastk
Dword
 
Mensagens: 4407
Registrado em: 14 Out 2006 20:43

Mensagempor B-EAGLE » 15 Abr 2011 11:46

aqui na empresa deu uma discussão lascada com o fato de se abrir chaves embaixo ou em cima.... tem algum padrão pra isso? particularmente me dá desespero ver um código com chaves abrindo embaixo... vai dar morte ainda isso! hauahauha
B-EAGLE
Word
 
Mensagens: 847
Registrado em: 19 Out 2006 14:12
Localização: Campo Grande - MS

Mensagempor brasilma » 15 Abr 2011 12:32

Não deveria ser "SensorAcionado"??? rsrsrs
" A Teoria orienta e a Prática decide" ;-)
Avatar do usuário
brasilma
Dword
 
Mensagens: 3621
Registrado em: 11 Out 2006 15:39
Localização: Planeta Terra

Mensagempor Jorge_Francisco » 15 Abr 2011 12:56

Eu sou o "do contra". Prefiro a chave que abre o bloco alinhada com a que fecha.

B-EAGLE escreveu:aqui na empresa deu uma discussão lascada com o fato de se abrir chaves embaixo ou em cima.... tem algum padrão pra isso? particularmente me dá desespero ver um código com chaves abrindo embaixo... vai dar morte ainda isso! hauahauha
Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Re: Estilo de codigo.

Mensagempor andre_luis » 15 Abr 2011 15:25

mastk,


Em certos casos, quando a variável é muito grande, mesmo em C, eu prefiro a abordagem por macros ( BIT_PORT_SENSOR ), do que uma estrutura do tipo : ( BufferSensor.Input.Debounced.Status = TRUE ).

Entretanto, já utilizei a segunda abordagem deliberadamente num código em C onde a portabilidade prevista para outro uC era mandatória, e para encapsular todas as implementações particulares á cada core num único arquivo, defini macros para isso ( Registradores SFR, acesso I/O bit-mapeado, etc... ).


+++
"Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."
Avatar do usuário
andre_luis
Dword
 
Mensagens: 5447
Registrado em: 11 Out 2006 18:27
Localização: Brasil - RJ

Mensagempor msamsoniuk » 15 Abr 2011 16:44

bom, desconsiderando possiveis otimizacoes, eu acho que macros em excesso criam problemas logicos. por exemplo:

#define TRUE 1
#define FALSE 0

if(x==TRUE) true();
if(x==FALSE) false();

eh bem claro e definido, mas nao eh uma boa ideia, pois a linguagem C define 0 como false e qualquer outra coisa como true, nao apenas 1:

if(x) true();
else false();

por exemplo, no caso de contadores que decrementam a cada interacao, eh comum usar:

timer()
{
if(x) x--;
else timeout();
}

o que por si jah eh uma interpretacao muito mais vasta do que apenas TRUE e FALSE. no caso do contador, faria algo como if(x!=FALSE) ? :)

mas isso pode ser utilizado de outras formas. por exemplo, eh tipico as funcoes de biblioteca retornarem zero para sucesso e qualquer outra coisa para erros, permitindo codificar os erros:

if(ret = funcao()) error(ret);

novamente, if(ret != FALSE) seria bem estranho! :)

jah no aspecto de otimizacoes, existe uma possibilidade sim do codigo gerado ser diferente, pois limitar o resultado entre 0 e 1 eh bem diferente de limitar o resultado entre 0 e +/- 2^31. a armadilha aparece justamente na tentativa de compactar o booleano e consumir menos memoria, afinal para expressar TRUE e FALSE precisamos de apenas um unico bit! no caso de um bitstream de um bit, as operacoes logicas necessarias sao obvias.

seja d0 um o bit zero da variavel d, temos entao:

if(d.d0 == TRUE)

uma operacao que requer uma mascara. a armadilha de gastar menos memoria pode ter outros efeitos colateriais: usar um unsigned char melhora, mas pode nao ser suficiente em processadores RISC modernos que sao otimizados apenas para operandos de 32 bits. entao o menor numero de instrucoes e maxima otimizacao pode ser usar:

if(d)

onde d eh um int de 32 bits.

xultz escreveu:Mastk, uma coisa que é dificil de explicar prá programadores é que encolher o código-fonte em C não diminui o tamanho dele compilado.
Fazer
if (x=y+3) ...
dá exatamente no mesmo que
x = y+3;
if(x) ...
que dá exatamente no mesmo que
x = y + 3;
if (x == 0) ...

Das três, eu prefiro a última, porque fica mais evidente o que o código deve fazer. Uma vez um livro chamado Practical C e ele mostrava versões compiladas e mostrava que o resultado era idêntico.

Uma outra abordagem interessante eu li no livro do Jack Ganssle, onde ele teoriza que a função mais importante do código-fonte não é ser compilado e funcionar, mas é ser legível e que um humano possa ler e entender seu funcionamento. Gerar um executável dele é mera consequência. E essa cultura deve ser implantada na equipe.
Ele defende que a empresa tenha uma documentação que descreva estética de código e fluxo de trabalho. Por estética de código, compreende-se forma de indentação, nomenclatura de variáveis e funções, estilo de comentários e documentação. Por fluxo de trabalho, procedimento de repositório, revisão de código, testes, etc.
É um assunto complicaod: dá trabalho fazer isso, é impossível chegar um concenso (já tentei criar um padrão de biblioteca de componentes eletrônicos aqui e desisti), mas depois de implantado, dá retorno porque todo mundo fala a mesma língua.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 15 Abr 2011 22:13

Quando pego código de terceiros e começo a arrancar os cabelos, a primeira coisa que faço é passá-lo pelo gnu indent, pra minimizar o choque. Eu nunca consegui acertar uma combinação de parâmetros dele que seja exatamente como eu costumo fazer, mas já chega próximo o suficiente pra que eu consiga importar pra um repositório meu sem ter a sensação de que tou colocando algo extremamente porco e/ou alienígena :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor leoabubauru » 16 Abr 2011 13:41

Creio que este assunto pese mais para o lado do gosto pessoal. É sabido que várias regras ajudam o código a ficar portável e/ou legível.

Eu já conhecia esta idéia do J. Ganssle. Ele vai além: Afirma que, quanto mais o código é visto em sua área, menor a chance de o projetista cometer erros e maior a chance de encontrá-los. Ou seja: comentários ao lado do código e não acima; Begin no fim da linha (como o 1º ex do mastk).

Eu prefiro o Begin identado e na linha seguinte. Mas o que ele defende faz sentido. Daí o sujeito que gosta daquilo usa isso como justificativa.

Outra coisa que concordo com o JG é que somos escritores, portanto o nosso código deve ser completamente legível. Comentários devem esclarecer idéias e conceitos, não linhas de código. Por isso prefiro

Código: Selecionar todos
if (SensorAcionada == TRUE)


a

Código: Selecionar todos
if (SensorAcionada)



Se a performance ficar comprometida com um
Código: Selecionar todos
if(d.d0 == TRUE)
em situações como a levantada pelo Marcelo Samsoniuk com 32bits, contrario meus princípios, mas comento ao lado como um código legível.


Eu uso estruturas como
Código: Selecionar todos
( BufferSensor.Input.Debounced.Status = TRUE )
pela facilidade de depuração, pois macros não aparecem no debugger. Tenho que ficar caçando no código o que significa cada macro.

Nomes de variáveis e funções eu faço: NomeDaMinhaVariavel. Não acredito que o idioma seja um problema. A menos que seja uma regra na empresa.
No meu caso, como já afirmei, vale a máxima: Sou um escritor de código.

Agora, o pior de tudo: A empresa tem regras claras e o sujeito não as segue. Isso me deixa puto!


Laercio
Tento, tento e tento...
Me arrebento!
Também bato!
Ô negocim bunitim essa tal eletrônica de barco!
leoabubauru
Byte
 
Mensagens: 227
Registrado em: 21 Nov 2006 19:08
Localização: São Paulo

Próximo

Voltar para Assuntos Gerais

Quem está online

Usuários navegando neste fórum: Google [Bot] e 1 visitante

x