api [nfc]: Use Dart-standard camel case throughout our source code #51
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will allow us to switch to the Dart standard convention of camel case within our source code, while still interoperating smoothly with the snake case in the Zulip API.
If the field names and parameter names used in the API bindings match the snake case of the Zulip API, then that will unavoidably propagate to some names found throughout the rest of our code -- as indeed it already has, as seen in this diff. There's no clean line that can be drawn within our source code so that snake-case names go on one side, and camel-case names on the other. So we'd inevitably have an unpredictable mix of both kinds of names, and often of the same name appearing in two different forms in the same code. That's what we see in the zulip-mobile RN app. Instead, draw that line at the very boundary of our code, where the data comes and goes via JSON. Happily the json_serializable code generator allows us to largely just write camel case and let the conversion to and from snake case be done automatically. Written by removing those ignore_for_file lines, and then using Android Studio's "rename" feature many times. Then grepped for `\w+(_\w+)+` to find stragglers in comments, and fixed those by hand. There's a couple of remaining stragglers in credential_fixture.dart, which I'll handle as a followup commit.
This is non-NFC because one needs to update `credential_fixture.dart`. (That's something I don't expect to happen more than once or twice more before we're able to do away with that mechanism entirely.)
|
Great, thanks! LGTM; merged, and I updated my |
This was referenced Apr 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the field names and parameter names used in the API bindings match the snake case of the Zulip API, then that will unavoidably propagate to some names found throughout the rest of our code -- as indeed it already has, as seen in this diff. There's no clean line that can be drawn within our source code so that snake-case names go on one side, and camel-case names on the other.
So we'd inevitably have an unpredictable mix of both kinds of names, and often of the same name appearing in two different forms in the same code. That's what we see in the zulip-mobile RN app.
Instead, draw that line at the very boundary of our code, where the data comes and goes via JSON. Happily the json_serializable code generator allows us to largely just write camel case and let the conversion to and from snake case be done automatically.
This PR also makes the same conversion for
credential_fixture.dart, which means one will need to update that file. (That's something I don't expect to happen more than once or twicemore before we're able to do away with that mechanism entirely.)