Namensgehäuse-Konvention über alle Sprachen in einer Anwendung

Ich baue eine Web-App mit Javascript (auf dem Browser), C # und Sql server. Ist es eine gute Idee, eine konsequente Namenskonvention in allen drei Sprachen zu haben?
Für Javscript, es scheint, beste Praxis ist, camelCase verwenden, aber in C # und Sql server ist es TitleCase.
Problem ist aber, wenn das Javascript verbraucht und sendet data an C # / Sql server die Namenskonventionen sind inkonsistent. Also muss ich Code schreiben, um sie zuzuordnen.

Beispielsweise

In Sql habe ich einen Tisch namens 'Foo' mit Spalten 'Name', 'EmailAdresse'

In C # habe ich ein POCO-object namens 'Foo', das diese Tabelle mit den properties 'Name', 'EmailAddress' abbildet und einen AIP-Endpunkt für GET ausgibt, das ist zB {"Name": "Joe Bloggs", "EmailAddres": "joe@test.org"}

Meine Javascripts macht einen Ajax-Aufruf, um diesen JSON zu erhalten und ihn einem eigenen JSON-object zuzuordnen, zB {"name": data.Name, "emailAddress": data.EmailAddress}

Diese Zuordnung zwischen Spalten- / Eigentums-Namenskonventionen scheint mir albern zu sein, und wäre nicht nötig, wenn alle Sprachen nur auf Gehäuse-Konvention vereinbart hätten. Gibt es einen besseren Ansatz dazu?

Meiner Meinung nach sollten Sie weiterhin die Standardkonventionen für jede Sprache verwenden.

Vorteile:

  • Konsistenz in jedem Stück Software.
  • Einfacher für Ihren Mitentwickler, da sie keine Homebrew-Namenskonvention (en) lernen müssen.
  • Es wird einfacher sein, Code an den Rest der Welt an Orten wie SO zu kommunizieren, oder wenn Sie sich entscheiden, eine Lösung zu implementieren, die auf SO gefunden wird.

Fügen Sie keine zusätzlichen Konventionen hinzu, um die Sprachen konsistent zu machen. Ihre Sprachen werden am Ende mit sinnlosen Regeln, die nicht relevant sind, und es wird verwirrend für jeden, der auf Ihrem Code in der Zukunft arbeitet.

Um den Anwalt des Teufels zu spielen, hier ist eine Meinung, die mit meiner von hier gestohlenen nicht einverstanden ist :

Hier finden Sie das große Problem mit Codierungsstandards, die auf Stil basieren – wenn Ihr Team nicht die gesamte Codebasis schreibt, dann werden Sie feststellen, dass Sie übereinstimmen mit dem anderen Code-Standard.

Also, mein Rat ist nicht zu schwitzen. Solange Ihr Code klar ist, ist es wirklich egal, ob Sie Kamelkoffer, Pascal-Etui oder Unterstrich verwenden. Es ist wichtiger, dass der Code lesbar ist.

Du solltest den Stil der 3. Parteien niemals verändern, denn der Vergleich mit neuen Versionen ist unmöglich, also musst du bei ihnen bleiben. Wenn du 2 verschiedene Bibliotheken hast, hast du keine andere Wahl, als einem Standard zu folgen, der den Codestil ignoriert. Es ist nicht so schlimm, wenn du ein guter Coder bist, kannst du jeden Code-Stil lesen. Wenn du es nicht tust, wenn du einen einsamen Stil hast, hilft dir überhaupt nicht.

Ich nehme es ein, weil ich denke, sie machen einen guten Punkt, und weil Sie an Ihrem eigenen Code außerhalb eines Team-Kontextes arbeiten. Allerdings ist es immer gut, gute Gewohnheiten zu üben (oder vielmehr schlechte Gewohnheiten zu vermeiden) auf Seitenprojekten, da sie sich durchführen könnten, um Sie mit / für andere zu schreiben, also wäre es sinnvoll, zu lernen, wie man mit Namenskonventionen umgehen kann große Codebasis, wenn Sie denken, dass Sie in diese Frage in der Zukunft laufen, während in einem Team.

Fügen Sie dies zu Ihrem Anwendungsstart hinzu, und es sollte automatisch das zurückgegebene object Ihres GET in camelCase umwandeln.

Keine Notwendigkeit, mit irgendwelchen Mappings zu verwechseln oder von den Konventionen jeder Umgebung zu streiten.

var formatters = GlobalConfiguration.Configuration.Formatters; var jsonFormatter = formatters.JsonFormatter; var settings = jsonFormatter.SerializerSettings; settings.Formatting = Formatting.Indented; settings.ContractResolver = new CamelCasePropertyNamesContractResolver(); 

Sehen Sie hier für mehr Details: http://odetocode.com/blogs/scott/archive/2013/03/25/asp-net-webapi-tip-3-camelcasing-json.aspx