Commentaires en ligne en Ruby

Est Ruby en mesure de comprendre des commentaires en ligne comme:

my_array = ['first', /* 'second', */ 'third', 'fourth']

?

Mise à jour:

J'ai demandé à pas sur ce qui est /* */en Ruby et pourquoi j'ai un message d'erreur, mais à propos de la présence de commentaires en ligne dans n'importe quelle forme à tous. /* */ont été donnés uniquement à titre d'exemple de commentaires en ligne connu pour moi.

  • C'est une très mauvaise habitude...
  • C'est pourquoi j'aime Codepad.org... 😀
  • Votre commentaire n'a aucun sens. L'OP demande si il y a une ligne de commentaire dans Ruby comme /* ... */, pas de savoir si /* ... */ est la syntaxe exacte si une telle chose existe.
InformationsquelleAutor Paul | 2012-10-29
  1. 30

    Non, Ruby n'a pas de commentaires en ligne.

    Des commentaires de ce style ont tendance à réduire la lisibilité, car ils rendent le code plus difficile à suivre.

    Dans votre cas, il serait préférable de diviser vos éléments de tableau en lignes séparées et commentez la ligne un.

    my_array = ['first',
#           'second',
            'third',
            'fourth']
    • +1. Lisibilité/entretien souffrir en faisant un commentaire sur la ligne.
    • Je ne pense pas que Ruby va perdre de la lisibilité s'il y en avait un. Vous venez d'avoir votre éditeur de texte détecter et marquer. Si j'étais Matz, je pense que j'irais le long des lignes de l'aide de l' %notation. Par exemple, peut-être quelque chose comme %c{...} peut être un bon candidat.
    • Parfois, les commentaires en ligne peut être très utile. Pas comme définitif de code, où la lisibilité est touché, mais pour désactiver une partie de la ligne de code temporairement.
    • Oh.Mon.Dieu. Vraiment? Ruby n'est PAS la langue qui doit être forçant pas à utiliser de la politique, car elle peut influencer la perte de lisibilité. Allez, Ruby a meta-programmation, fou constructions de code qui peut moignon tout, même expérimenté, développeur. Le rubis est la langue dans laquelle vous pouvez faire littéralement tout! À l'exception de commentaires en ligne. C'est juste fou.
    • eh bien, vous pouvez utiliser sleep(10) # just tired qui est en fait une ligne de commentaire non ?
    • "Les commentaires de ce style ont tendance à réduire la lisibilité, car ils rendent le code plus difficile à suivre." - Source?

    InformationsquelleAutor Douglas F Shearer
  2. 1

    Je voudrais juste ajouter que rdoc — Ruby intégré à la documentation constructeur peut utiliser les commentaires dans votre code pour générer un premier ensemble de documents. De ce que j'ai compris dans ma récente lecture, le "Ruby façon" suggère que votre code doit être lisible et auto-explicatif, mais que les commentaires sont précieux et simple de génération de la documentation dans le développement précoce, avant l'envoi d'un projet à une bonne équipe de documentation.

    Sur l'objet de commentaires en ligne, mon cas d'utilisation, c'est que je suis allongé sur un des paquebots de la cisr avant de l'intégrer à mon formatée correctement les fichiers source. Peut-être que beaucoup de gens ne me dérange pas de travailler avec des sauts de lignes dans leur environnement de développement, mais avec mes connaissances limitées de l'ensemble d'outils pour le moment, je suis de trouver qu'il est fastidieux de répéter les commandes précédentes. Je suis presque certain c'est dû à mon incapacité à analyser les outils à portée de main, que ce soit de la cisr, soulever et qu'est-ce-avez-vous. Pour le moment, je suis emballage de n'importe quel code qui j'ai envie de commenter inline à l'intérieur d'un objet de type string, qui je doit enlever ou de "décommenter" en enlevant l'enveloppe de chaîne.

    À prendre ou à laisser, mais ce sont mes deux cents! Garder sur Rubying sur!

    Addendum:

    Il paye pour lire la pry doc! Un pry méthode est liée à chaque objet, y compris le main. Appel il exécute un sous-shell dans le courant d'invite de commandes qui permet d'analyser un objet dans le champ d'application actuel. Il est disponible dans tout contexte, y compris la main pry. Couplé avec le amend-line, edit, hist, play commandes à Levier, ce rassasie mon désir de commentaires en ligne, même si je suis toujours pas au courant de toutes les caractéristiques de levier qui vous permettra de charger une commande précédente dans le courant de l'invite de saisie pour l'édition.

    Invoquant l'éditeur de texte tend à me distraire un peu juste, non seulement parce qu'elle supprime le contenu de la coquille de la mémoire tampon de la visibilité sur un seul écran (par ex. un ordinateur portable), mais surtout car il supprime tous les utile pry onglet les achèvements et les commandes. J'aimerais voir le soulever, ou un autre REPL permet d'utiliser le curseur sur plusieurs lignes, car je suis toujours à trouver la nécessité d'utiliser des one-liners.

    InformationsquelleAutor Tony Zielinski
  3. -4

    Lu tout ça avant d'en bas-vote 🙂

    Pour être honnête, vous ne devriez pas l'utiliser tout les commentaires, votre code doit être explicite.

    Je sais que cela semble hors sujet, mais écoutez-moi comme une suggestion pourquoi ils l'habitude de toujours mettre en œuvre ces types de commentaires en Ruby.

    Je tombe sur cette question, parce que je suis le traitement de nos clients laid API. Le JSON demande procesed de code Ruby ressemble à quelque chose comme ceci

    api_response = {
  headers: ["uniq_id", "email", "description"]
  rows: [
    [2345, '[email protected]', 'first item'],
    [9876, '[email protected]', 'second item']
  ]
}

    Donc, dans mon script je veux rassembler tous les uniq id:

    JSON.parse(api_response)
  .fetch('rows')
  .collect { |application_row| application_row.at(0) }

    il serait agréable d'avoir une certaine capacité à commenter ce que l' at(0) est l'extraction. Comme sawa c'est ce qui suggère dans son commentaire, si %c{} existerait que je pouvais faire quelque chose comme ceci:

    JSON.parse(api_response)
  .fetch('rows')
  .collect { |application_row|  %c{uniq_id}; application_row.at(0) }

    ...mais ensuite j'ai réalisé que je suis juste stupide. L'auto code doit lui expliquer mon intention

    uniq_ids = JSON.parse(api_response)
             .fetch('rows')
             .collect { |application_row| application_row.at(0) }

    Dans certains cas, ce n'est pas une option, donc peut-être que cela ferait l'affaire:

    JSON.parse(api_response)
  .fetch('rows')
  .collect { |application_row| uniq_id = application_row.at(0) }

    ...oui, cela va conduire à l'utilisation de inutilisés variable locale, mais dans ce cas c'est ok que la lisibilité de code serait à l'avantage de ne pas affecter les performances de trop.

    dans Pauls cas, il a juste envie de retirer un élément du Tableau. Je suppose qu'il veut sans doute pour le débogage but, mais l'idée générale est que Ruby vous forcer à vous écrire comme code propre que possible et enlever tout ce qui ne sera pas utilisé dans la production.

    solution, c'est peut-être

    my_array =  ['first']
# my_array += ['second']
my_array += ['third', 'fourth']

    Est-ce laid ? eh bien oui, c'est la pensée générale est que vous devez en tenir compte avant de vous engager, l'application vous pour supprimer laide code et supprimer inutiles plein de trucs avant de frapper à la production.

    mise à jour 2019 05

    Je vois cette réponse est de -1 à présent, Il a été publié en 2014. C'est en 2019 Et j'ai toujours le même avis 🙂 Si vous écrivez un commentaire, vous n'avez pas à écrire le code qui affiche clairement l'intention 🙂

    Il y a certainement des cas où le commentaire est nécessaire. Mais bon la réaction de développeur devrait être: "oh mon dieu, il y a un commentaire ! J'ai besoin de faire attention!"

    Je suis actuellement de 12 ans d'expérience professionnelle dans le domaine. Et vu ce cours et plus dans les projets: Si il y a un commentaire partout dans le code, les développeurs vont arrêter de voir des commentaires comme de précieuses informations et ne pas les lire.

    Mais en principe il n'y a pas un seul cas d'utilisation de la "nous allons placer un commentaire ici" qui ne peut être résolu avec un bon code/conception de l'architecture 🙂

    Pour ne citer que Martin Fowler:

    N'importe quel imbécile peut écrire du code que l'ordinateur peut comprendre. Les bons programmeurs d'écrire du code que les humains peuvent comprendre.

    • vous ne devriez pas utiliser les commentaires à tous C'est fou. Vous ne devriez pas utiliser stupide ou redondantes commentaires. Vous devez écrire du code avec les bons noms, propre et bien structuré; je suis d'accord avec le fait d'essayer de faire le code "lisible". Mais le code est faible, le niveau de détail de l'implémentation d'une plus niveau de la vision. Jusqu'à ce que "code" peut exprimer à la fois la mise en œuvre et de l'intention, vous aurez toujours besoin de commentaires pour écrire intention (et même arrière-plan derrière les trucs astucieux dans votre code).
    • ne peut pas être plus d'accord que le meilleur commentaire est le commentaire n'a jamais écrit. Le Code doit indiquer explicitement à l'intention. Cela étant dit, cette réponse de la mine est pour les situations où le promoteur n'est pas en mesure de le faire. Imaginez que vous travaillez avec le code existant, vous devez vous soumettre à changement rapide, et il n'y a pas de temps à refactoriser de bien décomposé objets.
    • Le code ne peut pas dire/exprimer une intention. Il ne peut que dire de la mise en œuvre. Indépendamment de la façon dont beaucoup d'un pressé de vous en (esp. si vous êtes pressé (e), bien écrit-commentaire peut guider le lecteur dans les manières, le code ne peut pas.
    • problème avec les commentaires c'est qu'ils sortent de jour facilement et puis les commentaires sont un mensonge. Code peut dire/ exprimer une intention tant que développeur n'est pas écrit il dans structurels de la programmation de la mode . Ruby, lorsqu'il est utilisé correctement, est belle langue qui peut bien exprimer tout ce que programmeur devrait normalement mettre de commentaire sans écrire un commentaire. Si quelqu'un a 1000 ligne de Contrôleur puis il n'a rien à voir avec l'objet de pratiques axées sur l' (même si Ruby) et que oui, il a besoin de commentaires.
    • Les commentaires de sortir de date n'est pas un problème avec les commentaires; c'est un problème avec les codeurs. Attribuer le blâme où il appartient.
    • yep, même de la discipline argument s'applique sur les codeurs envie d'écrire les commentaires 🙂 .Si ils se structure le code correctement, il n'y a pas besoin de commentaire.
    • Je suppose que nous arrivons à un point où tous les deux nous conviennent nous sommes en désaccord. J'ajouterai seulement un de plus de référence à mes arguments - Robert C. Martin - Propre codeur série. ep 5 Il assez bien résumer tout ce que je veux dire. Je sais que c'est 20$, mais je suppose que c'est la seule façon que je peux vous montrer ce que je veux dire sans passer des heures de discussion inutile de répéter les mêmes arguments.
    • Oui, nous allons en accord ou en désaccord. J'admire Martin, mais qui est différente de celle que je crois tout ce qu'il dit. J'ai beaucoup d'expérience de mon propre, et d'un point de vue unique basé sur construire un programme à grande échelle des outils de transformation et ont une très techniques de la compréhension de la différence entre l'intention et la mise en œuvre. Code est mise en œuvre. C'est pas intention. Alors, où obtenez-vous l'intention de partir? Fin de la discussion.
    • b.t.w.; une chose que je viens de rappeler. Un endroit où je pense que les commentaires ont de la valeur est dans les Tests de décrire la problématique des scénarios (à la fois dans l'Unité ou l'Intégration). Donc, si j'ai un scénario où j'ai besoin d'écrire un commentaire que j'ai écris dans un test. CEPENDANT 98% des cas, la RSpec "décrire" "contexte" et "elle", c'est assez pour décrire ce qui se passe et pourquoi. Je n'ai pas nécessaires voir la nécessité des outils comme le Concombre, Épinards (ou de tout autre Gerkin lang outil), sauf si l'équipe est trop junior. Si les Tests sont la vraie documentation dans le Code pas de commentaires.
    • J'ai utiliser les commentaires du document "insolite" aspects de dépendances externes (par exemple, un appel RESTE, téléchargé des fichiers CSV, de l'interaction avec un service qui en fait défie ses annoncés documentation...) qui NE se distingue pas seulement par la lecture de cette application du code. Pour arrêter un avenir dev (souvent moi) de dire..."C'est bête...lemme correctif janky code!" ...seulement pour briser l'application. Éventuellement, dans certains impairs scénario qui ne se passe pendant des MOIS après le "code d'amélioration".

    InformationsquelleAutor equivalent8