Vous êtes chef de projet. Un jour, l'un de vos programmeurs est devenu fou (ce n'est pas de votre faute ) et a pris toutes les expressions dans la base de code et leur a ajouté des crochets aléatoires, avant de quitter sur le champ, se plaignant de votre incompétence (ce n'est pas non plus votre faute ). Ce serait une solution facile, cependant, pour une raison quelconque, vous n'utilisez pas le contrôle de révision (ce n'est absolument pas votre faute ). Et pour une raison quelconque, aucun des autres programmeurs ne veut passer par chaque expression pour corriger les crochets incompatibles ( d'ailleurs, ce n'est pas votre faute ). Les programmeurs de nos jours, vous pensez à vous-même. Vous devrez le faire vous-même. L'horreur! De telles tâches étaient censées être sous vous ...
L'entrée sera une seule ligne, qui contiendra un certain nombre de crochets gauche ( ( [ {
) et de crochets droit ( ) ] }
). Il peut également, mais pas toujours, contenir des commentaires ( /* */
) et des littéraux de chaîne ( " "
ou ' '
) et divers chiffres, lettres ou symboles.
Il y aura au moins une parenthèse (en dehors d'un commentaire ou d'un littéral de chaîne) qui n'a pas d'opposé corrosif (en dehors d'un commentaire ou d'un littéral de chaîne). Par exemple, un errant }
sans a {
priori. Un autre exemple: un (
qui n'en a pas )
après. Votre programme remplacera par un espace le nombre minimum de parenthèses requises pour faire correspondre les parenthèses.
Exemples:
(4 + (2 + 3))]
==> (4 + (2 + 3))
(le crochet à la fin)
][][[]]
==> [][[]]
(le crochet au début)
("Hel(o!"))
==> ("Hel(o!")
(la parenthèse à la fin)
( /* )]*/
==> /* )]*/
(la parenthèse au début)
{()]
==> ()
(le crochet et le crochet carré)
- L'entrée peut être prise de la manière la plus pratique (STDIN, argument de ligne de commande, lecture à partir d'un fichier, etc.)
- S'il existe plusieurs façons de résoudre l'inadéquation avec le même nombre de suppressions, l'une ou l'autre est acceptable.
- Il n'y aura que des décalages entre parenthèses. Les littéraux de chaîne et les commentaires seront toujours correctement formés.
- Le titre vient de ce fil SO
- Il n'y aura jamais de citations dans les commentaires, de citations dans les citations, de commentaires dans les commentaires ou de commentaires dans les citations.
C'est le golf de code, donc le nombre minimum d'octets gagne. Posez des questions dans les commentaires si la spécification n'est pas claire.
la source
("foo (\") bar")
)?{{(})
devrait être{ }
ou équivalente, car le scénario d'ouverture implique que le code fonctionnait au départ et{(})
compte comme des crochets incompatibles dans tous les langages de programmation que je connais (c'est-à-dire "provoque une stase" ??). Mais alors, j'ai déjà écrit une réponse, donc je suis partiale.Réponses:
Ruby, 223 caractères
Celui-ci s'est avéré un peu long.
Ce qu'il fait est de retirer les chaînes et les commentaires en premier, afin qu'ils ne soient pas comptés (et les réintègre plus tard).
Ensuite, il parcourt la chaîne caractère par caractère. Lorsqu'il trouve une accolade ouvrante, il enregistre sa position. Lorsqu'il trouve une accolade fermante, il sort de sa matrice de stockage d'accolade ouverte respective.
Si
pop
renvoienil
(c'est-à-dire qu'il n'y avait pas assez d'accolades ouvrantes), il supprime l'accolade fermante. Une fois cette opération terminée, il supprime les accolades d'ouverture supplémentaires restantes (c'est-à-dire qu'il n'y avait pas assez d'accolades de fermeture).À la fin du programme, il remet toutes les chaînes et les commentaires et les renvoie.
Non golfé:
la source
(("string"/*comment*/)"string"
? Si je lis (la version non golfée) correctement, vous remplacez les chaînes et les commentaires par leur index dans leunparsed
tableau, ce qui conduirait à une substitution comme((12)3
et à la recherche d'un index12
(ou11
) inexistant . Je vois que la version golfée utilise seulementshift
, mais ne pourrait-elle pas encore avoir un problème similaire?Python 3,
410322317Essaie tous les ensembles de suppressions possibles, en commençant par les plus petits, jusqu'à ce qu'il en trouve un où les accolades sont équilibrées. (J'entends par là parfaitement équilibré:
{{(})
produit( )
, non{(})
.)La première version utilisait une fonction de générateur récursif, ce qui était vraiment cool mais aussi très long. Cette version effectue une recherche simple en largeur à l'aide d'une file d'attente. (Oui, c'est un algorithme de temps factoriel. Quel est le problème?: ^ D)
la source
C - 406
Une tentative en C sans utiliser d'expressions régulières.
Pour compiler et exécuter (sur une machine Linux):
gcc -o brackets brackets.c
./brackets "[(])"
Dans les cas non définis comme [(]), il renvoie la dernière paire de crochets valide ()
la source
Python 3, 320
Comme la solution de DLosc, cela étudie toutes les suppressions possibles, mais il utilise une stratégie d'exploration et de secours récursive qui est beaucoup plus rapide. Je sais que la vitesse n'est pas un critère dans le golf de code, et la recherche exhaustive est en tout cas exponentielle, mais celle-ci peut gérer des entrées comme
({({({({({({({({(}}}}}}}}
en quelques secondes.la source
O(n!!)
solution, nonO(n!)
. (Mon golf estO(n*2^n)
au lieu deO(2^n)
, car ilo
produit en fait tous les motifs avec desr
suppressions au lieu d'exactement desr
suppressions. Facile à réparer, mais cela coûterait quelques caractères.)