C'est le style ! :) - page 5

 

Urain писал(а) >>

e pense un instant que le style n'est qu'une habitude et rien de plus, une façon de penser.

Ce modèle s'est développé au fil des ans et, qui plus est, il continue de s'améliorer, bien que lentement. :)

Donc ce n'est pas une putain d'habitude. C'est trop difficile à faire. Mais ne pas mettre d'espaces entre les opérateurs - c'est - une mauvaise habitude chez un nombre étonnamment élevé de personnes.

 
Renat :

Non, le stylo ne sera pas ajusté.

C'est la réponse des développeurs. Sujet - fermé :(

 
Azzx писал(а) >>

Ce modèle s'est développé au fil des ans et, de plus, il continue de s'améliorer, bien que lentement. :)

Donc ce n'est pas une putain d'habitude. C'est trop dur. Mais ne pas mettre d'espaces entre les opérateurs - c'est une mauvaise habitude pour un nombre étonnamment élevé de personnes.

Et il est inutile de discuter du goût des huîtres - nous en avons mangé ! ;-) Je peux même vous dire les effets secondaires bénéfiques pour la santé de la consommation de ces fruits de mer. :-) :-)

pour le reste, il existe deux styles lisibles adéquats, presque équivalents :

if () {
}

и

if ()
{
}

tout le reste est bidon, IMHO.

ps. poignée de main Azzx

 

Exemples de normes de style C intra-entreprise - pour les systèmes INSTALLES (matériel) :

Dossiers :
1_2.zip  412 kb
2.zip  195 kb
3.zip  113 kb
 

Le problème peut avoir une solution très simple pour les deux parties.

Il suffit de conserver deux versions.

Les développeurs conservent la version formatée pour eux-mêmes - la manière dont ils sont à l'aise pour la traiter - et l'utilisateur conserve la version familière pour lui-même.

Dans ce cas, personne n'imposera rien à personne et le coût de l'espace disque supplémentaire et du temps nécessaire à un nouveau reformatage est insignifiant.

De plus, ceux qui veulent apprendre un style idéologiquement correct ont toujours la possibilité de regarder l'"idéal" :)

 
Shu >> :

en fait, si nous parlons de travail d'équipe, le plus important est que toute l'équipe travaille dans le même style de codage.

Personne ne le contestera si l'on est sain d'esprit. :)

Shu a écrit >>

quant à l'ensemble, il existe deux styles lisibles adéquats, presque équivalents :

и

tout le reste est bidon, IMHO.

Imho - également vrai. J'ai moi-même utilisé les deux. Juste la première version est un peu moins de lignes, et la lisibilité de la source n'en souffre pas. J'ai donc arrêté de le faire. :)
 
Andrei01 >> :

Le problème pourrait avoir une solution très simple pour les deux parties.

La solution au problème est ELEMENTAIRE. Déjà maintenant, le tabouret fonctionne et quelque part il y a une constante pour le nombre de positions pour indenter le support. L'ajout d'un champ de texte pour saisir cette même indentation dans les paramètres ME est un jeu d'enfant pour tout développeur. Tout.... sauf MK - ils ont leur propre "politique" à laquelle ils ont décidé de se tenir quoi qu'il arrive.

L'argument selon lequel il est nécessaire que le codebase soit en ordre général n'est même pas une excuse :)) Rédigez des règles d'acceptation des scripts où vous écrivez : les codes sont acceptés dans ce style. Si l'utilisateur envoie quelque chose d'autre, il reçoit la réponse standard "format tel que requis" et aucun code d'administration ne s'occupe de ce texte erroné.

Mais ce n'est même pas la question ! Combien de lignes de code MQL sont écrites dans le monde par jour ? Je pense que ce n'est même pas assez long pour ce nombre. Et combien d'entre eux finissent dans le codebase ? ! Je pense que short-a sera suffisant. Alors ne mentez pas, chers développeurs ;) Vos utilisateurs réels sont beaucoup plus nombreux que vos posters dans la base de code. Et plus votre produit sera pratique pour eux, plus il sera populaire. Ecrivez honnêtement - nous le ferons, mais plus tard, peut-être "très tard" ...... Tu craques comme tu l'as fait lors de la publication de la première bêta de Cinq... Je me sens mal pour vous :)

 
Renat :

Нет, стайлер останется без настроек.

ForexTools a écrit >>

Voici la réponse des développeurs. Sujet - fermé :(

malheureusement

--

reste :

1 trouver un autre styliste

2- utiliser le stock

---

chacun a sa propre perception du code

un bon code est rarement corrigé

Le code n'est pas toujours transmis avec le produit


même si je transmets le code, mon style peut ne pas être bien reçu par ceux qui sont habitués à...


if ( ) {
   ...
}

или
if ( условие )
  {
     ...
  }

void functionA()
   {
      ...
   }

j'écris dans ce style


void Function1()
{

}

if ( ) // условие входа
{

}


Il suffit de regarder dans le répertoire !

C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src\mfc\


c'est un style classique... c'est ce à quoi je m'en tiens.

 

Voici le fichier batch asty.bat en une ligne :


astyle.exe --indent=tab --indent=force-tab=3 --style=allman --delete-empty-lines --pad-oper --unpad-paren --pad-paren-out %1 %2 %3 %4 %5 %6 %7 %8 %9


et vous avez de la chance.

http://astyle.sourceforge.net/astyle.html

 

le style devrait être personnalisable, c'est l'affaire et la responsabilité du rédacteur de savoir à quoi ressemble le code...

Les développeurs ne nous reconnaissent pas en tant qu'écrivains...

lorsque vous devez utiliser des alternatives comme notepad++,

pour pouvoir travailler convenablement avec les doubles crochets, alors il n'est pas question de parler de styles...