Après un tour au Maroc, CodinGame, le challenge de programmation en ligne, revient le 29 janvier 2013 à 20h pour sa 3e édition.
L'occasion de se mesurer à plusieurs centaines d'autres codeurs, de remporter des Raspberry Pi 512 (+ accessoires) et, pour ceux qui le souhaitent, de décrocher un stage ou un emploi.
C'est gratuit, ouvert à tous, on peut participer de chez soi et c'est anonyme.
L’épreuve dure 4 heures maximum, où il faut essayer de résoudre 3 problèmes de programmation dans le langage de son choix parmi C, C++, Python, PHP, Java et C#.
L’environnement de développement proposé donne accès à un éditeur de code et un shell Bash, pour lancer son programme depuis le navigateur.
Dès la fin du concours, les scores et le classement général sont publiés. Pour que tout le monde puisse apprendre des bonnes idées des autres, le règlement prévoit que le code source des participants soit rendu public sous licence GPL v3 et affiché sur le site.
Quelques chiffres
400 codeurs au CodinGame d'octobre, 1200 à celui de décembre au Maroc, et pour l'heure, 800 inscrits pour le 29 janvier.
10 sociétés qui proposent plusieurs dizaines d'emplois / stages dans plusieurs villes de France.
Quelques exercices des éditions précédentes
Aller plus loin
- Page d'inscription (292 clics)
- Tutoriel pour s'entraîner (592 clics)
- Exemple d'exercice (690 clics)
- Site Internet de CodinGame (164 clics)
- Blog de CodinGame (110 clics)
# Impératif
Posté par Ontologia (site web personnel) . Évalué à 1.
Et une fois de plus, que des langages impératifs…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Impératif
Posté par Burps . Évalué à -4.
C'est pire que ça:
Lisibilité: 95 %Used builtin function 'map'(-5%)
(i.e. map(int, values) contre [int(x) for x in values] je suppose).
[^] # Re: Impératif
Posté par Blabla404 . Évalué à 6.
Il y avait déjà eu les mêmes remarques lors de la dernière annonce. La lisibilité n'est qu'une indication et n'est absolument pas prise en compte. (De toute façon comment voulez-vous automatiquement juger de la lisibilité d'un code ?)
L'usage de map fait de toute façon débat, pylint trouve que c'est pas terrible. Sans chercher à savoir quelle écriture est la plus compréhensible, s'ils utilisent ce genre d'outils pour noter le code, c'est normal que l'usage de map fasse perdre des points.
[^] # Re: Impératif
Posté par ckyl . Évalué à 2.
L'étape suivante c'est de coder pour faire plaisir aux 400 rapports Sonar totalement stupides mis en place par des "génies logiciels". Mais l'important c'est que ce soit vert sans chercher à comprendre pourquoi ! C'est gage d'un bon soft…
L'important c'est d'énnoncer des conventions et de pouvoir les justifier très facilement, pas de tourner à droite par ce qu'on te dit de tourner à droite. Les conventions Google sont très bonnes la dessus en justifiant toujours le pourquoi de leur décisions (et ils virent map/reduce d'ailleurs). Mais ca ne reste qu'un ensemble de choix parmis tant d'autres.
[^] # Re: Impératif
Posté par brendel . Évalué à 1.
Oui attention la notation se fait sur 1) le pourcentage de tests passé 2) Le temps mis pour passer toutes les épreuves. Un code lisible est donc plutôt désavantageux, puisqu'il est souvent plus long a écrire. C'est la que l'on voit que ce n'est pas un concours de programmation mais d'algo : Pour être bien classé, il faut trouver un algo performant et le coder à l'arrache (du moins, le plus vite possible).
Cela serait bien plus intéressant que le 2ème critère soit le temps d’exécution du code, comme ça entre 2 algo de même complexité, c'est l'implem la plus efficace qui est privilégiée. Mais je pense que ce serait trop dur de comparer des langages différent du coup.
[^] # Re: Impératif
Posté par Blabla404 . Évalué à 1.
D'un autre coté, certains tests sont gros et demandent donc un algo efficace pour être validé.
Alors effectivement ce n'est pas mesuré au quart d'instruction près, mais une mauvaise implementation ne passera beaucoup de tests.
[^] # Re: Impératif
Posté par brendel . Évalué à 2.
Heu tu entends quoi par "mauvaise implémentation" ? A priori une fois que tu as trouvé l'algo de la complexité qu'ils attendent, tu passes tous les test (la taille des entrées est précisée pour chaque exercice). Que tu le code à l'arrache ou pas n'y change rien. C'est pour ça que c'est plus un concours d'algo que de programmation. Je trouve juste que c'est dommage que pour départager les ex æquo on retienne le temps d'écriture du code. Si le temps d’exécution (ou la mémoire utilisée) rentrait en jeu, il faudrait avoir une implémentation plus efficace de l'algo que l'on a trouvé.
[^] # Re: Impératif
Posté par Blabla404 . Évalué à 1.
Je mettais juste en avant le fait qu'il faut un algo de bonne complexité, mais en fait tu l'avais déjà remarqué.
Après sur des petits problèmes (typiquement il faut qu'ils soient faisable chacun en moins d'une heure) ça me parait vraiment très dur de mettre un score en fonction du temps d'exécution. Hors le fait que ça mets certains langages directement hors jeu, il s'agit ensuite généralement de petites optimisations qui vont pas mal dépendre du compilo, donc c'est assez dur de tester chez soi avant de soumettre le problème.
Intel propose régulièrement Accelerate your code où tu as un accès à la machine de test et il faut optimiser au mieux le programme, mais effectivement ce n'est pas du tout le même genre de challenge.
[^] # Re: Impératif
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Suffit alors de programmer en Scheme avec Gambit-C et de compiler vers C.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.