-
-
Notifications
You must be signed in to change notification settings - Fork 18.8k
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
base: master
Are you sure you want to change the base?
Conversation
is this also possible in gdscript ? if not, can it be implemented ? |
Yes, this is suppported since Godot 3.0. |
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.
60e068d
to
09571e0
Compare
Rebased against latest |
@@ -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; |
There was a problem hiding this comment.
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
Maybe it's just me, but this looks awful, prefer the old way! 😁 |
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 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 |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
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; |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Not particularly against this, but for those like me used to low level, hex in lowercase if unreadable. Hex should always be uppercase. |
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:
0x([0-9a-FA-F']+)
0x\L$1
thirdparty,*.po,*.pot
(+ VCS ignores)