Fix capitalisation of SI units

[kurahaupo]

What does this implement/fix? Please describe.

• The source code has seemingly randomly chosen upper/lower case SI abbreviations, in contravention of the SI specification.

Other info

• The SI specification for Metric abbreviations is case sensitive, so adjust the spelling of MHz & GHz to match that specification.
• Write number—unit rather than unit—number (and add a descriptive prefix where necessary to avoid having a digit at the start of an identifier).

Not fixed

• The "2 GHz" band is misnamed, since it's only about 100 MHz wide, not 1 GHz wide. As a future task, perhaps 2GHz should be changed to 2400MHz

Where has this been tested?

• This only renames classes, constants, and variables. I've checked for conflicts with existing names and there are none, so if it compiles, it will run.

[VREMSoftwareDevelopment]

Please merge the latest feature branch into si_capitalisation

This PR is showing too many changes.

[codecov[bot]]

Codecov Report

Merging #425 (4777100) into feature (0a0bb41) will not change coverage. The diff coverage is 98.91%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## feature #425 +/- ## ========================================== Coverage 92.58% 92.58% Complexity 901 901 ========================================== Files 130 130 Lines 2696 2696 Branches 233 233 ========================================== Hits 2496 2496 Misses 58 58 Partials 142 142 ```

[kurahaupo]

@VREMSoftwareDevelopment rebase & conflict resolution done

[VREMSoftwareDevelopment]

Thank you for your PR.

Is it possible to split this pull request into 3 smaller pull requests (2.4, 5 and 6 GHz)? It is very hard to review so many changes at once.

Please use Kotlin Coding conventions when changing or adding new code.

• Property names
• Enumerations

Thanks again for the PR.

[kurahaupo]

I've tentatively done this, but it actually increases the number of chunks that need to be reviewed.

Are you reviewing each commit separately, or the whole lot in one go? If the latter it's going to be awkward because combined renaming and editing often confuses "diff" into thinking that a bunch of files have been deleted and a bunch of unrelated files have been added.

I'm wondering if it would be easier to review the list of search-and-replace commands instead? That's only about a dozen lines.

[kurahaupo]

To recreate the changes introduced by this PR:

• cd /path/to/repo
• git checkout feature -b temp425
• wget -O patch.bash https://github.com/VREMSoftwareDevelopment/WiFiAnalyzer/files/12035564/patch.txt
• bash patch.bash
• git log -n11 --pretty=oneline

Satisfy yourself that the result is the same as this PR; e.g.:

• git log -n11 kurahaupo/si_capitalisation --pretty=oneline
• git diff @..kurahaupo/si_capitalisation

Clean up:

• git branch -D temp425
• git checkout feature

Then read the patch file itself to reassure yourself that all the changes are sane.

If you think that the capitalisation of b in bandNNGHz or bandwidthNNMHz should be different, it is simple to change the patching script; let me know what you'd like.

note: the point of this is that GHz and MHz should have exactly those capitalisations unless there are technical (not just stylistic) reasons for them to be otherwise.

(Previous version: ~patch.bash~)

[kurahaupo]

To be honest, I'm not entirely sure about the resource names; I've included them because there appears to be some automation that converts resource foo_bar into Kotlin identifier fooBar, but maybe that's just coincidence?

Feel free to omit those commits if I have this wrong.

[VREMSoftwareDevelopment]

Are you reviewing each commit separately, or the whole lot in one go?

https://github.com/VREMSoftwareDevelopment/WiFiAnalyzer/pull/425/files

[VREMSoftwareDevelopment]

The code changes do not comply to Kotlin coding conventions

Reference documentation:

• Kotlin Coding conventions
• Property names
• Enumerations

[kurahaupo]

Is there any point to me continuing with this?

I only started this because I found the mix of "Ghz", "ghz", "GHZ", "Mhz", "mhz", and "MHZ" very distracting and therefore harder to read. None of those is compliant with the Metric Convention.

You haven't given any explanation or examples of how the patch breaches each of the coding conventions, but it seems like your primary objection is that changing the capitalisation of "MHz" and "GHz" is not allowed by the Kotlin coding conventions. If that's not you primary objection then please say so.

Coding conventions are supposed to make code easier to read and easier to manage, but the key is understanding how rigorously they should be applied, especially when they directly conflict with other conventions. (The Metric Convention is used by more than 7 billion people, which to my mind means it takes precedence over lesser conventions.)

Is there any accommodation that would satisfy both of us?

[VREMSoftwareDevelopment]

Making code more readable is always a plus. Making code more readable while violating coding standards is a minus.

It is recommended that:

• end user visible text should comply to the Metric Convention
• Kotlin code should comply to the Kotlin Coding Standards

By making a smaller PR, will allow to comment exactly on the changes that violate Coding Standards

You haven't given any explanation or examples of how the patch breaches each of the coding conventions, but it seems like your primary objection is that changing the capitalisation of "MHz" and "GHz" is not allowed by the Kotlin coding conventions. If that's not you primary objection then please say so.

It depends where, some place it is okay to have GHz, some other once it is not.

Kotlin Coding conventions

Commonly known and easy-to-follow coding conventions are vital for any programming language. Here we provide guidelines on the code style and code organization for projects that use Kotlin.

Configure style in IDE

Two most popular IDEs for Kotlin - IntelliJ IDEA and Android Studio provide powerful support for code styling. You can configure them to automatically format your code in consistence with the given code style.

[kurahaupo]

By making a smaller PR, will allow to comment exactly on the changes that violate Coding Standards

Even replacing one item would make a patch well in excess of 100 lines, so I don't see how a "smaller PR" would help. (I followed the suggestion to subdivide into 2GHz, 5GHz & 6GHz, and I'm pretty sure that's made the situation worse rather than better.)

Rather than review the whole PR, how about just commenting on these:

within	decl	old name	new name	ok / not ok
package	val	availableGHZ6	available6GHz	?
class	val	channelAvailableGhz6	channelAvailable6GHz	?
class	fun	channelAvailableGHZ6	channelAvailable6GHz	?
class	val	channelAvailableTitleGhz6	channelAvailableTitle6GHz	?
R.id		channel_available_title_ghz_6	channel_available_title6_g_hz	?
class	fun	channelsGHZ6	channels6GHz	?
class	val	expectedGHZ6	expected6GHz	?
enum class	?	GHZ6	band6GHz	?
enum class	val	ghz6	is6GHz	?
class	val	wiFiChannelGHZ6	wiFiChannel6GHz	?
package	class	WiFiChannelCountryGHZ6	WiFiChannelCountry6GHz	?

I can't see how the symbol GHZ6 is declared, so I don't know what its kind is, and therefore I don't know which style rule applies to it. Is it perhaps an enum?

I've written _g_hz in the resource names because I assume that snake_case resource names map to camelCase names, and that's what I need to match GHz elsewhere in the code. If that assumption is wrong I'll gladly drop that transformation because it looks even uglier than the original.

I suspect that having val channelAvailableGhz6 and fun channelAvailableGHZ6 is not ideal. Should one of them be renamed to make the val/fun distinction clearer?

[VREMSoftwareDevelopment]

Install Kotlin Coding conventions in the Android IDE

Run (Analyze) Android IDE Inspect Code -> Analyzer

Take a look at the Inspection Results Kotlin Section

All the Kotlin Code issues should be available there