Et bien? Est-ce considéré comme une mauvaise pratique?

OMI, c'est moins lisible. Je déteste devoir faire défiler vers la droite, puis vers la gauche, la droite, la gauche, etc. Cela rend le codage plus douloureux et m'embrouille parfois.

Par exemple, chaque fois que je coderai une longue chaîne, je ferai ce qui suit ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

Oui, en effet, au sens littéral comme au sens général.

J'aime faire des différences de code côte à côte, et les lignes trop larges rendent cela plus difficile:

Des langages comme Scala avec des chaînes entre guillemets triples vous permettent de construire une chaîne à partir de plusieurs lignes sans les frais d'exécution, les guillemets disgracieux et les signes plus (comme dans votre exemple) de réunir des parties d'une chaîne.

Oui, je pense que 80 caractères par ligne sont raisonnables et couramment utilisés.

C'est une question vraiment importante pour moi! J'ai travaillé 7 mois sur un ordinateur portable 13 "avec des collègues ayant des moniteurs de bureau 24", et je me suis retrouvé à passer beaucoup de temps à raccourcir les lignes pour aboutir à quelque chose de lisible.

80 colonnes est un peu petit dans de nombreux cas (sauf si vous travaillez sur un terminal avec vi la seule option;)), mais plus de ~ 150, c'est trop (voir ci-dessous).

C'est pour la pure question de «lisibilité».

Maintenant, pour la partie `` bonne pratique '', je trouve très souvent que de telles lignes longues sont défectueuses, c'est-à-dire qu'elles ont une partie qui devrait être extraite dans une variable temporaire, ou qui est dupliquée, par exemple (ObjectiveC, extrait de code commun dans la programmation iPhone) :

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

Veuillez noter que cela peut devenir encore plus désagréable lorsque vous travaillez avec des vecteurs ou matrices tridimensionnels.

Exemple réécrit:

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

Cela s'adapte maintenant sur un écran plus petit, plus facile à déboguer à l'aide d'un IDE ou d'une écriture sur la sortie standard, et pourrait même être plus rapide, selon le coût de l'appel de méthode / propriété. C'est un peu forcé bien sûr, la plupart des exemples du monde réel sont beaucoup plus complexes ...

Pas toujours.

Juste pour ajouter une vue alternative, lorsque je lis du code, je peux souvent obtenir l'essentiel de ce que fait la ligne de code sans avoir à lire la ligne entière. Si je peux lire le nom de la méthode mais que les paramètres de la méthode débordent de l'écran, je ne suis normalement pas dérangé car je peux dire à partir du seul nom de la méthode quelle est l'intention de cette ligne de code. Si quelques lignes de code débordent de l'écran, je pense que le compromis de devoir parfois (mot important là-bas) défiler horizontalement en vaut la peine pour le code plus compact. Je trouve parfois le code multi-ligne à instruction unique distrayant car je dois reconstituer mentalement quel code va avec quelle instruction.

Souvent, les lignes de code qui débordent horizontalement ont leurs bits importants à gauche (visible) et les bits moins importants à droite (hors écran), donc pour moi cela améliore la lisibilité car je peux balayer le code vers le bas en voyant principalement le bits importants sur chaque ligne, par opposition à l'alternative d'avoir les bits de code moins importants d'une ligne trop longue occupant l'espace gauche visuellement important sur la ou les lignes suivantes.

Cela dit, je ne voudrais certainement pas faire défiler horizontalement très souvent, mais je trouve cela moins problématique en ces jours de moniteur à écran large.

Oui.

Soit dit en passant un pourboire. Si vous utilisez un langage avec des chaînes multi-lignes (pratiquement tous les langages de script en ont) et que vous incluez du SQL long, cela aide vraiment la lisibilité de placer le SQL dans une chaîne multi-lignes en utilisant des règles de formatage cohérentes pour le SQL. Voir http://bentilly.blogspot.com/2011/02/sql-formatting-style.html pour le style de formatage que j'utilise.

Non, non.

J'ai un éditeur. Non seulement il a un retour à la ligne, mais il a une indentation de retour à la ligne , ce qui (si l'écran a une largeur de 100 caractères) entraînerait

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

apparaître comme

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

ou avec le niveau d'indentation défini par défaut pour la langue actuelle.

Des lignes plus larges que mon écran ne rendent jamais le code moins lisible que le code indenté par un retour automatique à la ligne.

edit: ooooh, je savais que cette réponse serait impopulaire :)

C'est certainement le cas. Il y a une raison pour laquelle les journaux et les magazines utilisent des colonnes. La lisibilité est un facteur important. En lisant nos yeux, balayez vers le bas avec relativement peu de mouvement latéral. L'effet est de permettre à nos yeux de scanner rapidement ce que nous lisons.

Même lorsqu'ils sont visibles à l'écran, des colonnes larges obligent nos yeux à faire des allers-retours rapides. Pendant le balayage, nous ne comprenons vraiment rien. Cela ralentira considérablement la lecture et la compréhension. L'effet est similaire aux anciennes imprimantes mécaniques. Celles-ci nécessitaient souvent l'insertion de plusieurs caractères nuls après un retour chariot pour laisser le temps au chariot ou à la tête d'impression de se repositionner pour la ligne suivante.

De plus, la disposition verticale est généralement effectuée de manière à clarifier le regroupement du contenu sur la ligne. Cela ne devrait généralement s'appliquer qu'aux conditions logiques composées. Les formules longues peuvent être mieux structurées comme une série d'énoncés. (L'optimiseur corrige toute surcharge supplémentaire et certains optimiseurs abandonnent ou fonctionnent mal sur des formules complexes.)

Les identifiants avec plusieurs points nécessitant de grandes lignes indiquent des techniques de codage qui doivent être rectifiées.

Les souris-roues facilitent le défilement vertical rapide ... le défilement horizontal est trop cher en comparaison.

Évitez le défilement horizontal.

~ Consignes d'interaction avec l'expérience utilisateur Windows, page 112

Oui.

Les Anglais lisent de gauche à droite, ce qui entraîne un défilement constant = non productif

Pour cette raison, j'active toujours le retour automatique à la ligne avec des glyphes de ligne visuelle dans mon IDE.