Le plus rapide

Tous les tests se feront sur la même machine, avec la même version de 4D monoposte avec une structure compilée par le testeur. La version de 4D sera toujours la plus récente. Les bases développées dans une version antérieure sont acceptées, la structure étant alors convertie sans aucune retouche. Certains challenges pourront faire appel à du code plus spécifiquement orienté 4D Server, la méthodologie des tests sera alors précisée. Le temps passé à valider d'éventuels dialogues (ouverture de document, confirmation...) n'est pas pris en compte. Les tests se feront parfois sur un Mac, parfois sur un PC, les bases étant alors transportées dans un sens ou dans un autre. Aucun plug-in n'est accepté sauf si l'intitulé autorise clairement son utilisation. Dans ce cas, il s'agira de plug-in gratuit tel l'ACI_Pack. Une exception à la règle du "sans plug-in" : 4D Chart qui est inclus dans 4D, et peut donc être utilisé librement si nécessaire. Seuls peuvent apparaître dans les dossiers Mac4DX et Win4DX les fichiers utilisés par le code (ressources séparées de la structure...) Les codes manipulant les datas feront l'objet de tests répétés pour tenir compte de la gestion du cache interne par 4D.

Le plus compact

Est considéré comme " compact " un code contenant le moins de caractères, exception faite des commentaires et des lignes vides. Il s'agit uniquement de la taille des méthodes (objet, formulaire, trigger, projet, base). La taille des formulaires, dessins de décors... n'est pas prise en compte. Dans certains challenges, on tiendra compte de la taille des tables (nombre de champs, types des champs...) lorsque la structure de la base fera intimement partie du problème. La longueur de noms des méthodes, variables et autres objets n'est pas pris en compte afin de ne pas forcer les développeurs à utiliser des noms idiots tels v1 à v100 ou m1 à m100.

Le moins bogué

Le code devra pouvoir être compilé sans erreur, les warnings sont acceptés. Afin de ne pas pénaliser les concurrents ne possédant pas 4D Compiler, les corrections minimes seront faites automatiquement (équilibre des parenthèses, par exemple). S'il y a conflit de type, la structure pourra être retournée au concurrent avec le fichier d'erreur afin qu'il modifie le code lui-même. En cas d'égalité stricte entre concurrents, il sera tenu compte de ce qui améliore la lisibilité du code : clarté et concision des commentaires, cohérence globale des noms et termes utilisés... Haut page