ASM51

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.

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.

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.

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

Opinião própria.
Se o código é de uso exclusivo,não ha nescessidade de ser 'universal'.
Mas,Variável com nome universal...

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.

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

http://net.pku.edu.cn/~course/cs101/200 ... nguage.pdf

Desculpem, deixei ambiguo, digo eficiencia em codificação, os exemplos que demostrei a saida é a mesma, claro.

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

Não deveria ser "SensorAcionado"??? rsrsrs

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

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... ).


+++

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.

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

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