Pour répondre à tes questions :
- La casse dépend de la convention proposée/imposée par le langage. C'est aussi une histoire de lisibilité : si tu respectes la casse, en un coup d'oeil, un lecteur comprendra la nature de l'identifiant. Pour ma part, sauf contre-indication du langage, c'est toujours camelCase pour les méthodes, snake_case pour les fonctions et pour les identifiants (variables, etc.). En Python, c'est "un peu plus délicat" vu que tout est objet, et que n'importe quel identifiant peut contenir à peu près n'importe quoi (méthode, fonction, objet, classe, ...). Ce qui fait qu'en "statique" dans le code, je respecte les conventions, et dès que j'introduis un identifiant, c'est snake_case.
- Espace, pardi ! On n'est pas à quelques caractères près au niveau du stockage du code, et c'est BEAUCOUP plus pratique, notamment quand tu changes d'éditeur ou que tu travailles en groupe sur le code. Et si VRAIMENT quelqu'un veut utiliser des tabulations, c'est un tab = 4 espaces, et pas 8 ! (A nouveau, c'est surtout parce que je travaille en Python et comme l'indentation est obligatoire pour délimiter les structures de contrôle, t'as pas envie de te retrouver à 80 caractères juste parce que t'es dans 10 structures de contrôle ^^).

Si en python tout est objet, en JS tout est fonction ! ;)

J'ai vu pas mal de flamewar 2 espaces vs 4, mais la tab de 8 espaces, ça, je crois n'avoir croisé que rarement.

Je fais surtout du dev Drupal en ce moment, et si tu veux respecter les conventions d'écriture, c'est tellement normé que tu discutes même pas de ça avec les autres devs :

Commentaires : à minima du Doxygen sur les fonctions,
Tabulation, obligatoirement 2 espaces (en même temps, 4 espaces, c'est moooooooooooooche !)
Concaténation : espace point espace
Noms de fonctions en snake_case
...etc...

L'avantage, c'est que c'est toujours facile à lire, vu que tous les modules communautaires (et la communauté Drupal est très grande) respectent tous cette convention.

Comme quoi les belges...

Côté C#, j'étais habitué à 4 espaces pour la tabulation, mais depuis 1 an, on m'a imposé 3 espaces pour 1 tabulation et je n'y ai vu que du feu

Par contre, côté C#, toutes les fonctions, constantes, propriétés sont en PascalCase.
Il n'y a que pour les variables locales que tu utilises du camelCase, et jamais de snake_case, le "_" est tabou, à part peut-être pour des variables privés d'une propriété:

private string _name;
public string Name {
get { return _name; }
set { _name = value }
}

Mais maintenant, C# nous propose directement :
public string Name { get; set; }
Et c'est foutrement pratique

Edit: pourquoi la mise en page du [ code ] [/ code ] est différente selon que c'est sur 1 ligne ou plusieurs ?

PetitCalgonEdit: pourquoi la mise en page du [ code ] [/ code ] est différente selon que c'est sur 1 ligne ou plusieurs ?

Pour pouvoir écrire du code inline et un bloc de code. Si y a qu'une seule ligne, c'est du inline, si y a plusieurs lignes, ça fait un bloc. Il faudrait que je regarde pour que le "bloc" soit dans la même police que le inline tiens...

PetitCalgonJ'ai pris l'habitude de projets entièrement en anglais, vous codez aussi en anglais?

Parce que sur le principe, un
public bool EstTerminé()
ou un
public bool IsFinished()
c'est pareil

public bool EstTerminay()

Mon commentaire préféré jusqu'ici est

// au secours, je suis coincé dans une SSII!

Joker Prudhommes, Joker Démission, Joker Préavis, Joker Rompre Période d'essai

krapouJe fais surtout du dev Drupal en ce moment, et si tu veux respecter les conventions d'écriture, c'est tellement normé que tu discutes même pas de ça avec les autres devs :

Marrant, pour faire du Drupal et du Symfony en même temps, je me sens vachement plus à l'aise pour les normages en Symfony que les "normages à l'arrache" de Drupal.

Après, c'est les goûts et les couleurs, mais j'ai du mal à supporter le snake partout, alors avec Drupal je suis servis ...