Método de Avaliação

[Prog 183]

Olá pessoal...

 

Resolvi criar este post para tentar criar um padrão de avaliação dos duelos, embora este "padrão" ainda esteja se desenvolvendo, então, aqui poderão dar todas as opiniões necessárias para poder melhorar este "padrão".

 

MEDINDO A VELOCIDADE:

 

Para medir a velocidade, uso uma parte de uma classe, que segue o código abaixo:

class timer{
	var $time = array();

	function startTime(){
		$this->time['start'] = $this->getMicrotime();
		return $this->time['start'];
	}

	function endTime(){
		$this->time['end'] = $this->getMicrotime();
		return $this->time['end'];
	}

	function getMicrotime(){
		list($usec, $sec) = explode(" ",microtime());
		return ((float)$usec + (float)$sec);
	}

	function timeElapsed(){
		return $this->time['end'] - $this->time['start'];
	}
}

$t = new timer();
$t->startTime();

// função a ser analisada

$t->endTime();
echo "<br><br>".$t->timeElapsed();
exit;

CONTANDO AS FUNÇÕES INTERNAS DO PHP:

 

Esta é a mais simples... basta ser um conhecedor da linguagem.

Então... O que não é contabilizado?

- Estruturas de Controle ( http://br.php.net/manual/pt_BR/control-structures.php )

- array() não é contabilizada ( http://br.php.net/manual/pt_BR/function.array.php )

 

CONTANDO AS LINHAS:

 

Esta é a tarefa mais complexa e a unica forma que eu tenho de "explicar" é mostrando exemplos.

 

1. while (...) {
2.   processo ...;
3.   if (...) {
4.	 processo ...;
x.	 continue;
x.   }
5.   processo ...;
x. }

1. switch(...){
x.   case 0:
2.	 processo ...;
x.	 break;
x.   case 1:
3.	 processo ...;
x.	 break;
x.   case 2:
4.	 for(...){
5.	   processo ...;
6.	   processo ...;
7.	   processo ...;
x.	 }
x.	 break;
x.   default:
8.	 processo ...;
x. }

x. function exemplo(...){
1.   processo ...;
2.   processo ...;
3.   processo ...;
4.   if (...) {
x.	 return variavel;
x.   } else {
5.	 return processo;
x.   }
x. }

 

Fico aguardando criticas e sugestões.

Caso haja necessidade de incluir algum novo requisito, se o mesmo for relevante, será acatado para as avaliações.

Qualquer dúvida, questionem.

 

ps.: Não considerem este como sendo o método utilizado para avalização de todos os duelos, o mesmo já sofreu melhorias.

[Fabyo 66]

só pra recordar e ver se falta alguma coisa

 

* Se a função nao esta exatamente de acordo com o que foi pedido perde 10 pontos

* Se a função tiver algum Notice ou erro mesmo perde 10 pontos

* Se a função tiver detalhes a mais que a função original ganha-se 10 pontos

* O lance de poucas linhas acredito que deveria contar no maximo 5 pontos, porque se vcs verem mesmo na real pra um sistema funcionar com precisão o numero de linhas é irrelevante , as vezes um sistema é muito melhor que outro e ele nao deveria perder só por causa de umas linhas amais

acho que deveria ver tbm quando uma pessoa faz alguma coisa pouco inteligente poderia perder 1 ponto exemplo:

 

$query = "select * from tabela";

mysql_query($query);

 

poderia ter feito assim direto:

mysql_query("select * from tabela");

 

ou outro exemplo que pessoas ficam passando valor de variavel pra variavel sem precisar

 

$campo = $_POST["campo"];

$nome = $campo;

$novo_nome = funcao_quaquer($nome);

 

sendo que poderia ter feito diretamente:

$nome = funcao_qualquer($_POST["campo"]);

 

é só um exemplo, mas tem casos parecidos que pessoas complicam algo simples e isso poderia contar a favor de quem tem mais domino com a linguagem acho que é mais importante que contar linhas, claro que pode ter os pontos por linhas mas como falei as linhas nao sao o ponto mais importante da função

[Perfect Lion 10]

MUTANTE_POWER_B-> então mutante... é por isso que está aqui para discuções... para vermos como vamos analizar daqui pra frente os duelos.... para não haver nenhum problema mais.. :) A ideia do fabyo sobre estruturar melhor o codigo gostei...pois o objetivo desse topi é até chegarmos a criar um sistema analizador de codigo.. mais o sistema terá os moderadores que podem liberar quais membros vão postar a função no analizador...e dando assim o reultado mais preciso por igual.. para não ter diz que diz... vou ver se crio um mini sistema para testarmos ... :)

[Prog 183]

MUTANTE _POWER_B

Quando trabalhamos para nós mesmos, e sabemos que apenas nós teremos acesso a um determinado código, concordo plenamente que, a forma adequada de trabalhar é aquela com a qual simpatizamos, mas, apartir do momento em que existe mais de 1 participante, este metodo passa a não ser mais aceitavel.

 

Exemplos do seu código:

function abc($a) { if ($a > 5) { return $a * 3 } else { return $a / 2}}

 

Um outro problema foi quanto ao uso dos identificadores, não seria bem mais prático se você usasse algo como $intTamanhoPalavra do que simplesmente $a ???

 

Pode estar muito claro para você, mas para quem vai avaliar, não é bem assim não... encare isto como um professor de calculo numerico corrigindo seus erros de português em uma prova de matemática. Você pode saber muito matemática, mas a partir do momento em que você comete falhas, cabe a você aceitá-las.

 

Resolver o problema nem sempre esta diretamente relacionado com resolver da melhor maneira.

 

Parabéns novamente pelo seu script.

E desculpe se a minha analise o faz pensar que agi de forma injusta.

[Prog 183]

Fabyo...

Resumindo... é um pouco disto tudo que você colocou ai. Com relação as linhas, sim, sabemos que isto não influencia diretamente na resolução do problema, mas, concorda comigo que quanto menor a solução mais simples de interpreta-la???

 

Isto é uma questão de "o que realmente é relevante para a analise", se for contabilizar as instruções vai ser uma tarefa estremamente trabalhosa. Apesar de achar que isto não vai influenciar num resultado, observado que o que realmente faz a diferença é a velocidade que o script chega a solução, esta caracteristica seria mais como um critério de desempate, caso viesse a ocorrer. Pelo que eu mencionei ali em cima... acho um script menor bem mais simples de compreender que um script maior.

 

* Detalhes a mais... pontos positivos.

* Detalhes a menos ou mal funcionamento... pontos negativos.

* Mensagens inesperadas... pontos negativos.

 

* Acho que um bom entendimento e explicação do que esta acontecendo é válido, quem vai avaliar, muitas vezes, fica perdido tentando interpretar o que esta acontecendo... muito mais se formos começar a avaliar o quão inteligente o participante foi ao criar uma determinada parte do código.

[Fabyo 66]

Entendo Prog, o lance das linhas tbm concordo, só acho que é injusto avaliar um script porque teve uma linha a menos que o outro mas o que tem uma linha amais tem maior chances de nao dar erro nenhum porque o cara precavel usando um debuger seila, mas é só nesses casos onde a função esta bem mais funcional e elaborada do que outra que só funciona numa situação e nao funciona em outra, de resto esta tudo certo

[Perfect Lion 10]

Criei um simples sistema que verifica quantas funções você está usando

http://www.baratoweb.com.br/analisar/index.php

 

ele conta tbm repetidos... pois eu considero que está mesmo assim usando ela novamente ;)

[Fabyo 66]

aqui nao abriu o link

[PauloFreitas 0]

Criei um simples sistema que verifica quantas funções você está usando

http://www.baratoweb.com.br/analisar/index.php

 

ele conta tbm repetidos... pois eu considero que está mesmo assim usando ela novamente ;)

He He He ... tá bugado (rs). :nataltongue:

 

Criei essa função:

<?phpfunction getTime(){	return date('H:i:s', time());}?>

Ele só está contabilizando o uso da função date(). :natalsad:

 

Quando trabalhamos para nós mesmos, e sabemos que apenas nós teremos acesso a um determinado código, concordo plenamente que, a forma adequada de trabalhar é aquela com a qual simpatizamos, mas, apartir do momento em que existe mais de 1 participante, este metodo passa a não ser mais aceitavel.

Hmm ... como cada um programa de um modo, poderíamos então, criar ou seguir um padrão (coding standard) para o desafio. Minha sugestão é seguirmos o padrão PEAR Coding Standards, que é um dos mais, senão o mais conceituado hoje em dia. O que acham ? :natalsmile:

 

[]’s :natalbiggrin:

[Fabyo 66]

outra coisa bugada é se você ficar clicando em enviar ele vai escapando as aspas sem parar:

 

function getTime()
{
return date(\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'H:i:s\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\', time());
}

?>

 

e sobre o modo do cara programar nao é sobre identação e regras, mas sim outras maneiras que serao avaliadas

[Perfect Lion 10]

v1d4l0k4 -> num ta bugado não kra... eu criei ele para verificar quantas funções internas do PHP você está usando.. pois quanto menas funções melhor lembra??? e ele conta mesmo assim se você usou 2 vezes a mesma função...pois continua usando :) Fabyo-> Arrumado... :) o que podemos colocar mais???

[Prog 183]

Perfect Lion...

O que ele quis dizer é que o seu script esta contabilizando apenas date(), quando ele deveria contabilizar date() e time().

 

v1d4l0k4...

Não que deveriamos usar um ou outro padrão, é como o Fabyo disse. Eu não quero saber se esta sendo usado um método FulanoHyper Patterns ou se esta usando o Prog Patterns, o que interessa é ser "Entendivel Patterns". *rs*

 

Se o cara usar um padrão, ótimo, mas se ele usar padrão nenhum e ainda entregar um código todo zuado, bem... isto pode contar negativamente.

[klawdyo 0]

Na minha opinião apenas o tempo de execução e a quantidade funções internas deveriam entrar nos critérios de pontuação. Mas, se por algum acaso, acontecer um empate, caso os participantes viessem a utilizar a mesma forma de resolução, por exemplo, então poderíamos contar a quantidade de linhas. E outra coisa, o Sistema de Avaliação de Desafios Imasters Automatizado (SADIA) deveria ser o tema do Desafio 5. Assim, a partir dele, poderíamos fazer, de forma equilibrada, as avaliações dos códigos para determinarmos as chaves do Brasileirão. E no SADIA poderia ter uma área de envio dos códigos dos participantes, uma área de cadastro, de geração de duelos, onde os interessados se inscreveriam, e a área de avalia~çao deveria ser aberta, para todos pudessem testar os códigos para ver se tá bom... quando voce abrisse um duelo entre, por exemplo, Prog X Sillent para ser finalizado no dia 31/12, ou quando os dois entregassem os códigos, então o sistema encerraria automaticamente o recebimento dos códigos e j´exibiria os resultados. Aí os participantes seriam avisados por e-mail, que o desafio terminara.... p****.. são muitas ideias...MAs, pra deixar claro, o desafio seria criar APENAS a função de avaliação.. o restante do sistema seria reformulado aos poucos.. ou então, alguém poderia fazer um e indicar para ser o padrão, desde que usasse a função vencedora... Aliás, ela poderia ser modificada, para acrescentar melhorias ou critérios adicionais.

[Prog 183]

Taí... klawdyo...

 

Gostei do tema para o Desafio 5... vou propor. :)

Vai ser um desafio um pouco mais demorado, mas acho que da certo da gente fazer.

 

Teriamos que pensar todos os requisitos do sistema antes de lançar... vou colocar a idéia lá no post do Desafio 5.