Quelle était la règle de codage la plus étrange que vous ayez été obligée de suivre?
Quand j'ai demandé cette question j'ai presque toujours un oui catégorique, vous devriez avoir des normes de codage.
Quelle était la règle de codage la plus étrange que vous ayez jamais été obligée de suivre?
Et par étrange, je veux dire le plus drôle, ou le pire, ou tout simplement étrange.
Dans chaque réponse, veuillez indiquer la langue, la taille de votre équipe et les effets néfastes qu’elle a causés.
avoir à mettre le préfixe m_ sur Java variables d'instance et le préfixe g_ sur Java variables statiques, la plupart des non-Java imbécile avec lequel j'ai eu à traiter, perpétué par les développeurs C et C++ qui ne savaient pas utiliser autre chose que le bloc-notes pour développer Java avec!
sauf que personne ne l'a réellement suivie, sauf pour mettre m_ sur tout, même la statique, même les noms de méthodes ...
Nos anciennes normes de codage c # exigeaient que nous utilisions d’énormes blocs de commentaires laids. Vous savez dans Code Complete où Steve McConnell donne un excellent exemple de macro de commentaire laid? Cette. Presque une correspondance exacte.
La pire chose à ce sujet est que c # est un langage qui a déjà un bon support (et relativement discret) pour les commentaires.
Vous obtiendrez quelque chose comme ça:
/// <summary>
/// Add an item to the collection
/// </summary>
/// <parameter name="item">The item to add</parameter>
/// <returns>Whether the addition succeeded</returns>
public bool Add(int item) { ... }
et cela se transformerait en ceci:
// ########################################################## //
/// <summary>
/// Add an item to the collection
/// </summary>
/// IN: <parameter name="item">The item to add</parameter>
/// OUT: <returns>Whether the addition succeeded</returns>
// ########################################################## //
Notez que la coloration syntaxique de StackOverflow ne le rend pas justice, car avec le schéma de texte VS par défaut, le symbole # est vert clair, entraînant une violation accablante de vos rétines.
Je ne peux que supposer que les auteurs étaient vraiment très friands de ses précédentes expériences avec C/C++. Le problème était que, même si vous n'aviez que quelques propriétés automatiques, cela prendrait environ 50% de l'espace de votre écran et ajouterait un bruit important. Les lignes supplémentaires // ont également gâché le support de refactoring de R #.
Après avoir abandonné la macro de commentaire, nous avons fini par fesser toute la base de code avec un script qui nous ramènerait au style de commentaire c # par défaut de Visual Studio.
La pire norme de codage que j'ai jamais eu à vivre était l'indentation folle.
Le code avait été écrit à l’origine sur un ordinateur central à l’aide de terminaux à écran vert de 60 caractères sur 80 caractères (il ya assez longtemps). La taille de tabulation par défaut de ces éléments était de 8 caractères, mais les programmeurs de l’époque ont alors décidé que c’était trop grand: l’écran lui-même n’affiche que 80 caractères; une tabulation de 8 caractères a donc perdu beaucoup d’espace.
Ils ont donc décidé de définir la taille de l'intention de leur code sur 4 caractères.
Très bien, dites-vous. Sauf qu'ils ne l'ont pas fait en modifiant la taille de l'onglet. Ils l'ont fait en faisant du premier retrait 4 espaces, le second un seul caractère de tabulation, et ainsi de suite en alternant entre l'ajout de 4 espaces et un caractère de tabulation.
Tandis qu'ils collaient aux terminaux à écran vert, c'était très bien. Bizarre, mais bien.
Le vrai chaos a commencé lorsque l’équipe de développement a reçu ses nouveaux PC Windows brillants.
L'éditeur de PC choisi avait une taille de tabulation de 4 caractères. Ainsi, lorsque le code était chargé, l'indentation était simplement omniprésente.
Nous ne pouvions pas réparer l'indentation car certains développeurs utilisaient encore les écrans verts. Ainsi, pendant toute l'année qui a nécessité la transition de toute l'équipe vers des PC, nous avons eu un cauchemar absolu en essayant de travailler avec un code pratiquement illisible l'un ou l'autre environnement (ou plus fréquemment, les deux).
À l'époque de COBOL, nous devions utiliser trois astérisques pour les commentaires (COBOL n'exige qu'un astérisque dans la colonne 7). Nous avions même un pré-compilateur qui vérifiait cela et ne compilerait pas votre programme si vous utilisiez autre chose que trois astérisques.
La première langue que j'ai utilisée professionnellement était 4D. Il supportait les variables interprocess préfixées par un <>, les variables processus sans préfixes et les variables locales commençant par $. Tous ces préfixes (ou leur absence) sont utilisés par le compilateur/interprète pour déterminer la portée de la variable.
La norme de codage étrange réelle était une sorte de notation hongroise. Le problème était que, au lieu de nommer les variables en fonction de leur type, elles devaient être préfixées en fonction de leur étendue.
Les variables, dont la portée était déterminée par leur préfixe, devaient être précédées d'informations redondantes!
Je n'ose pas demander au responsable des normes pourquoi cela devait se passer ainsi ...
Utilisez _ ou m_ devant la variable globale lorsque vous pouvez simplement utiliser le mot clé this. quand vous avez besoin d'accéder à la variable globale ...
Dans mon dernier emploi, mon superviseur a toujours appliqué la loi de Murphy:
"Tout ce qui peut aller mal ira mal."
J'imagine que c'était pour que nous n'ayons pas relâché quelques corrections rapides dans le code ou quelque chose du genre. Et maintenant, j'ai constamment cette phrase dans ma tête.
Le plus étrange était "cela doit être codé en C++". Vraisemblablement, je suis embauché pour mon expertise. Si mon opinion d'expert dit qu'une autre langue ferait mieux le travail, alors cette autre langue devrait être celle qui est utilisée. Me dire quel outil je devrais utiliser revient à dire à un mécanicien automobile qu’il est uniquement autorisé à utiliser des clés métriques. Et seulement des clés.
Capitaliser les acronymes
DO majuscule les deux caractères des acronymes à deux caractères, à l'exception du premier mot d'un identifiant à la casse.
System.IO
public void StartIO(Stream ioStream)
DO ne met en majuscule que le premier caractère d’acronymes de trois caractères ou plus, à l’exception du premier mot d’un identifiant composé d’un chameau.
System.Xml
public void ProcessHtmlTag(string htmlTag)
NE PAS mettre en majuscule l'un des caractères d'un acronyme, quelle que soit sa longueur, au début d'un identifiant chamellé.
Mon ancien patron a insisté pour que nous utilisions des constantes à la place d'énums, mais nous n'avons jamais donné de raison. Dans tous les scénarios, ils ont été utilisés, un énum étant plus logique.
Le mieux était cependant d'insister pour que tous les noms de table soient singuliers, puis de rendre les classes de code également. Mais non seulement ils représentaient l'objet, tel qu'un utilisateur ou un groupe, mais ils représentaient également la table et contenaient tous les CRUD pour cette table et de nombreuses autres actions. Mais attendez, il y a plus! Ils devaient également contenir une collection nom/valeur visible publiquement afin que vous puissiez obtenir les propriétés avec un indexeur, par nom de colonne, au cas où vous ajouteriez une nouvelle colonne mais ne vouliez pas ajouter une nouvelle propriété. Il y avait beaucoup d'autres "choses à faire" qui non seulement n'avaient pas de sens, mais qui ont également eu un impact important sur les performances du code. Je pourrais essayer de les signaler tous, mais le code parle de lui-même et, malheureusement, il s’agit presque d'une copie exacte de la classe User que je viens d'extraire d'un ancien dossier d'archives:
public class Record
{
private string tablename;
private Database database;
public NameValueCollection Fields;
public Record(string TableName) : this(TableName, null) { }
public Record(string TableName, Database db)
{
tablename = TableName;
database = db;
}
public string TableName
{
get { return tablename; }
}
public ulong ID
{
get { return GetULong("ID"); }
set { Fields["ID"] = value.ToString(); }
}
public virtual ulong GetULong(string field)
{
try { return ulong.Parse(this[field]); }
catch(Exception) { return 0; }
}
public virtual bool Change()
{
InitializeDB(); // opens the connection
// loop over the Fields object and build an update query
DisposeDB(); // closes the connection
// return the status
}
public virtual bool Create()
{
// works almost just like the Change method
}
public virtual bool Read()
{
InitializeDB(); // opens the connection
// use the value of the ID property to build a select query
// populate the Fields collection with the columns/values if the read was successful
DisposeDB(); // closes the connection
// return the status
}
}
public class User
{
public User() : base("User") { }
public User(Database db) : base("User", db) { }
public string Username
{
get { return Fields["Username"]; }
set
{
Fields["Username"] = value.ToString(); // yes, there really is a redundant ToString call
}
}
}
désolé si cette double publication, la première fois je pourrais ne pas être humain ou peut-être que le site a juste une limite à comment mauvais code peut être posté
"Les gars qui ont écrit le compilateur sont probablement beaucoup plus intelligents que vous, alors n'essayez pas quelque chose d'intelligent", a déclaré l'un des documents de référence (pas tout à fait littéralement).
Postfixer _ aux variables membres. par exemple.
int numberofCycles_;
C'était en C++ sur un projet open source avec quelques développeurs. L'effet secondaire principal était de ne pas savoir qu'une variable avait une portée de classe avant d'arriver à la fin du nom. Ce n’était pas une chose à laquelle j’avais beaucoup réfléchi auparavant, mais clairement à l’arrière.