Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use C++14 number separators for large numbers, lowercase for hexadecimal #44224

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Calinou
Copy link
Member

@Calinou Calinou commented Dec 9, 2020

This makes large numbers easier to read.

Decimal numbers are split starting from 7 digits (in groups of 3). Hexadecimal numbers are split starting from 8 characters (in groups of 4, except ASCII characters which are split in groups of 2).

Hexadecimal numbers were also converted to lowercase for better readability when mixed with numbers.


For reference, this was used for converting hexadecimal numbers to lowercase:

  • VS Code regex for searching (case-sensitive): 0x([0-9a-FA-F']+)
  • Replace with: 0x\L$1
  • Files to exclude: thirdparty,*.po,*.pot (+ VCS ignores)

@barbaros83
Copy link

barbaros83 commented Dec 9, 2020

is this also possible in gdscript ? if not, can it be implemented ?

@Calinou
Copy link
Member Author

Calinou commented Dec 9, 2020

is this also possible in gdscript ? if not, can it be implemented ?

Yes, this is suppported since Godot 3.0. 123_456_789, 0xFFFF_0000 and 0b1001_1111 all work (binary literals were added in 3.2).

@aaronfranke
Copy link
Member

I think it would be better to use scientific notation in many of these cases: https://www.cplusplus.com/reference/ios/scientific/

I think this is only for floats/doubles, but it can still be assigned to an int with implicit truncation.

This makes large numbers easier to read.

Decimal numbers are split starting from 7 digits (in groups of 3).
Hexadecimal numbers are split starting from 8 characters (in groups of 4,
except ASCII characters which are split in groups of 2).

Hexadecimal numbers were also converted to lowercase for better
readability when mixed with numbers.
@Calinou Calinou force-pushed the use-cpp14-number-separators branch from 60e068d to 09571e0 Compare May 3, 2022 21:59
@Calinou Calinou requested review from a team as code owners May 3, 2022 21:59
@Calinou Calinou removed request for a team May 3, 2022 21:59
@Calinou
Copy link
Member Author

Calinou commented May 3, 2022

Rebased against latest master and tested on demo projects, it works successfully.

@@ -187,7 +187,7 @@ void Input::get_argument_options(const StringName &p_function, int p_idx, List<S
void Input::VelocityTrack::update(const Vector2 &p_delta_p) {
uint64_t tick = OS::get_singleton()->get_ticks_usec();
uint32_t tdiff = tick - last_tick;
float delta_t = tdiff / 1000000.0;
float delta_t = tdiff / 1'000'000.0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For floating-point literals, it's worth considering the exponential form 1e6 instead.

EDIT: Oh, I already suggested this in 2020 :P

@lawnjelly
Copy link
Member

Maybe it's just me, but this looks awful, prefer the old way! 😁
Seems a bit like a solution in search of a problem... but am happy with what the majority want to go for.

@neikeq
Copy link
Contributor

neikeq commented May 4, 2022

Seems a bit like a solution in search of a problem...

If you're referring to the number separators, they solve a well defined problem. When reading code, you can't tell right away what number 10000000 is. You have to count the digits. With 10'000'000 it's clear right away.

I do think it makes hex values look worse and it adds little benefit there. I would only use it for hex values larger than 32-bits.

@@ -33,7 +33,7 @@

#include "core/io/file_access.h"

#define ENCRYPTED_HEADER_MAGIC 0x43454447
#define ENCRYPTED_HEADER_MAGIC 0x43'45'44'47
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't consistent with 0xffff'ffff used in other places.

I'm not sure either makes sense to me, if anything I'd put separators every byte (so none here, only when there's more than 8 bits).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two hex digits are one byte. One hex digit is 4 bits. So this is already separators every byte.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah indeed! Then I guess it makes sense, though it still looks a bit overkill to me to separate every 2 or even 4 hex digits.

Copy link
Member Author

@Calinou Calinou May 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's best do this on a case-by-case basis. I'll revert changes made to hexadecimal numbers, except in two situations:

  • Numbers with more than 8 hexadecimal digits (will be separated every 4 digits).
  • Numbers that represent binary file magic (will be separated every 2 digits).

Does this sound good?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it useful? Splitting it into bytes doesn't make in more readable, probably better to add a // ASCII "GDEC" comment and uses 4 digit splits, like other places do.

}

static const float AUDIO_PEAK_OFFSET = 0.0000000001f;
static const float AUDIO_PEAK_OFFSET = 0.000'000'000'1f;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1e-10 would be better here IMO.

Comment on lines +991 to +998
const static real_t s_c3 = 0.946'174'695'75; // (3*sqrt(5))/(4*sqrt(pi))
const static real_t s_c4 = -0.315'391'565'25; // (-sqrt(5))/(4*sqrt(pi))
const static real_t s_c5 = 0.546'274'215'29; // (sqrt(15))/(4*sqrt(pi))

const static real_t s_c_scale = 1.0 / 0.91529123286551084;
const static real_t s_c_scale_inv = 0.91529123286551084;
const static real_t s_c_scale = 1.0 / 0.915'291'232'865'510'84;
const static real_t s_c_scale_inv = 0.915'291'232'865'510'84;

const static real_t s_rc2 = 1.5853309190550713 * s_c_scale;
const static real_t s_rc2 = 1.585'330'919'055'071'3 * s_c_scale;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks pretty weird to me on arbitrary decimal numbers.

IMO using number separators makes sense for things like 10'000'000, but for the arbitrary result of a computation, I don't think it's useful. This is copy pasted output from a calculator/terminal and the only way to proofread it is to just copy paste a new value on top and check the diff. It's not something that you have to read by intermediate units.

@@ -56,7 +56,7 @@
#define UNIT_EPSILON 0.001
#endif

#define USEC_TO_SEC(m_usec) ((m_usec) / 1000000.0)
#define USEC_TO_SEC(m_usec) ((m_usec) / 1'000'000.0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#define USEC_TO_SEC(m_usec) ((m_usec) / 1'000'000.0)
#define USEC_TO_SEC(m_usec) ((m_usec) / 1e6)

@@ -86,7 +86,7 @@ int Math::step_decimals(double p_step) {
// Only meant for editor usage in float ranges, where a step of 0
// means that decimal digits should not be limited in String::num.
int Math::range_step_decimals(double p_step) {
if (p_step < 0.0000000000001) {
if (p_step < 0.000'000'000'000'1) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (p_step < 0.000'000'000'000'1) {
if (p_step < 1e-13) {

@@ -411,7 +410,7 @@ class Math {
uint64_t i;
} u;
u.d = g;
u.i &= (uint64_t)9223372036854775807ll;
u.i &= (uint64_t)9'223'372'036'854'775'807ll;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could maybe be replaced by a constexpr to calculate it at compile time instead of hardcoding.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, ~(1ll << 63), or 7F'FF'FF'FF'FF'FF'FF'FF

@reduz
Copy link
Member

reduz commented Jul 29, 2022

Not particularly against this, but for those like me used to low level, hex in lowercase if unreadable. Hex should always be uppercase.

@akien-mga akien-mga modified the milestones: 4.0, 4.x Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants