| Time |
Nick |
Message |
| 03:01 |
|
SFENCE_arch joined #luanti-dev |
| 04:09 |
|
Thomas-S_ joined #luanti-dev |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 06:55 |
|
SFENCE_arch joined #luanti-dev |
| 07:41 |
|
fgaz joined #luanti-dev |
| 12:01 |
|
rdeforest_ joined #luanti-dev |
| 12:17 |
rdeforest_ |
I'm continuing to dig into issue-15795 |
| 12:40 |
MTDiscord |
<astra008.> Beware of lava |
| 12:41 |
rdeforest_ |
does the `m_` prefix on object members such as `LocalPlayer.m_sneak_node_exists` signify "private member"? |
| 12:59 |
pgimeno |
#15795 |
| 12:59 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15795 -- Cannot sneak through open door |
| 14:20 |
[MatrxMT] |
<Zughy> Can we finish #15322 ? |
| 14:20 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15322 -- Minetest → Luanti rename checklist |
| 14:47 |
sfan5 |
maybe |
| 14:48 |
sfan5 |
rdeforest_: it just signifies "member variable". we don't use that for new code however |
| 15:27 |
|
SFENCE_arch joined #luanti-dev |
| 16:04 |
MTDiscord |
<herowl> sfan5: why isn't it used anymore? I thought it's a good convention, clears up a lot of confusion when using implicit this. |
| 16:31 |
rdeforest_ |
I would argue that I can rely on my IDE to tell me what a symbol refers to |
| 16:32 |
rdeforest_ |
It's the same reason I object to polish notation where the variable or parameter name starts with type information. I let the tools worry about that. |
| 16:32 |
rdeforest_ |
But I'll defer to the community preference if there is a difference |
| 16:34 |
rdeforest_ |
sorry, hungarian, not polish. |
| 16:34 |
rdeforest_ |
I see in the style guide that "The prefix m_ is discouraged for public members in newer code as it is a part of the class interface, but sometimes needed for consistency when adding a member to older code." |
| 16:55 |
MTDiscord |
<luatic> imo m_x sucks because it forces you to write obj.m_x, which adds exactly zero value and is just annoying verbosity. |
| 16:55 |
MTDiscord |
<luatic> whether we should use explicit this ought to be a different discussion, but i agree that if it is unclear, you can always let your tooling come to the rescue. |
| 16:57 |
rdeforest_ |
That is my thinking exactly |
| 16:59 |
MTDiscord |
<warr1024> If you ever need naming conventions to distinguish between name, Name, m_name, etc then you're probably already doing plenty wrong anyway... |
| 17:01 |
MTDiscord |
<warr1024> Though the greatest sin is still having names that would collide without the casing/naming conventions ... |
| 17:11 |
sfan5 |
explicit this is stupid, with very limited exceptions |
| 17:13 |
MTDiscord |
<luatic> i've used quite a few languages which have explicit "this" (often called "self", or you get to pick a name for it) so i wouldn't mind it terribly much tbh ¯_(ツ)_/¯ |
| 17:20 |
|
Desour joined #luanti-dev |
| 17:26 |
Krock |
sfan5: I'd prefer to keep the m_ notation for private or protected members. It's a handy convention to distinguish the lifespan of a variable inside functions |
| 17:26 |
Krock |
was this officially changed? |
| 17:27 |
sfan5 |
🤷 |
| 17:29 |
Desour |
I also like the m_ prefix. it makes side effects of member functions much more obvious. foo.m_y is of course of no value, and yes if we need m_ to distinguish member vars from local vars, we do something wrong: implicit this, which is c++'s fault |
| 17:31 |
Desour |
(for structs without member functions, m_ is useless though) |
| 17:32 |
Desour |
(and implicit this has it's usefulness, if you treat a class as something like an environment with variables) |
| 17:54 |
MTDiscord |
<josiah_wi> I used to m_ all member variables in my code, but I've since changed to using this-> in accesses instead for the reasons luatic and rdeforest shared. |
| 17:55 |
MTDiscord |
<josiah_wi> Warr, the convention is (well, should not be) to distinguish names in competing scopes, but to notice while reading a method whether an accessed variable is a member or not. |
| 17:56 |
sfan5 |
I'd rather have m_ than this-> |
| 17:56 |
sfan5 |
the latter is more annoying to type |
| 17:56 |
sfan5 |
and distracting |
| 17:57 |
MTDiscord |
<josiah_wi> I keep noticing how my typing speed affects my style preferences. Typing speed of a team should be taken into account when setting style guides lol. |
| 17:57 |
MTDiscord |
<josiah_wi> But then if you need to replace someone you might have to find a candidate with a high typing speed... |
| 18:00 |
MTDiscord |
<warr1024> When I worked in C#, this.x vs x both meant the same thing when x existed as a member field but not as any kind of more local identifier. this.x would have been more annoying to type if we had been typing it out in a text editor, but since x was in practice usually much longer, typing this. and then autocompleting was a lot more efficient. |
| 18:00 |
MTDiscord |
<warr1024> In some cases these kinds of practices end up guided by the tools you use, which actually rather sucks when one of your project's principles is to support developers using their own choice from a wide variety of available tools. |
| 18:03 |
MTDiscord |
<warr1024> Josiah: typing speed itself (as typically measured) probably correlates a lot with programming experience anyway so it's probably not as big a factor as you'd worry ... but whether somebody is relying on advanced tools like autocomplete/intellisense, or is trying to stay in practice with simple tools so they're always ready to do an emergency fix in plain vi over ssh, can make a huge difference. |
| 18:04 |
MTDiscord |
<warr1024> (and I guess overreliance on fancy tools can create economic barriers for prospective devs; I'm not sure how big of a factor this really is, but it could be a thing and worth thinking about...) |
| 18:04 |
MTDiscord |
<josiah_wi> Warr, I believe it's a bigger factor than most people realize, because most programmers are probably around the 85-110 WPM range, which doesn't have that much variance. |
| 18:04 |
|
SFENCE_arch joined #luanti-dev |
| 18:05 |
MTDiscord |
<josiah_wi> However, I do have classmates who can't touch type, and they spend a non-negligible amount of their programming time just finding keys to press, both coding and typing commands. |
| 18:05 |
MTDiscord |
<josiah_wi> It is hard to imagine such a person ever using an editor such as vim, where you use a lot of extra keypresses to get things done. |
| 18:06 |
MTDiscord |
<josiah_wi> My own typing speed is now around 160 raw, which you will not be able to obtain simply through programming experience. You have much more experience than I do, Warr, and I don't think you can come close to my typing speed. |
| 18:07 |
MTDiscord |
<josiah_wi> For me, I really don't care that much how much I have to type. I don't even care if my workflow is inefficient, because the speed difference with saving one or two commands on the CLI for example is negligible. |
| 18:07 |
MTDiscord |
<josiah_wi> I often type git status after every command as a reflex, sometimes when it's unnecessary and makes no sense to do so. |
| 18:09 |
MTDiscord |
<josiah_wi> sfan5 cites the annoyance of typing this-> as a reason not to use it in addition to it being noisy to read, and that makes sense if you feel that little bit of extra time it takes to type, because you do it over and over and it slowly builds annoyance. |
| 18:10 |
MTDiscord |
<josiah_wi> One morning during my internship I was naming a bunch of things with the prefix dbgctl, which in Dvorak is all on the right hand, and my finger joints hurt so bad I had to take a break from work. Even for someone who types as fast as I do, there are still certain words which are physically painful to type, and now the keyboard layout changes which words are good vs bad, and you're back to the problems with supporting every developer's |
| 18:10 |
MTDiscord |
personal tools lol. |
| 18:21 |
|
SFENCE_arch joined #luanti-dev |
| 18:38 |
|
hwpplayer1 joined #luanti-dev |
| 18:40 |
MTDiscord |
<warr1024> I think last time I measured my typing speed, it was like 90 or something, but in practice I usually say "60" because I'm rarely trying to type that fast. Even at 60, my typing speed is more often limited by thinking anyway. |
| 18:40 |
MTDiscord |
<warr1024> I am, after all, a programmer ("software engineer" where that distinction matters) rather than a typist. |
| 18:41 |
MTDiscord |
<warr1024> Ohhh, you're a dvorak user. Well that kinda makes sense then. |
| 18:44 |
MTDiscord |
<warr1024> Usually I design things to work okay with people who type at about my speed or faster, and that's plenty broad enough. If people are struggling with the limitations of typing speed below my level, it's pretty rare that they've got enough actual practical programming experience to not already be struggling with some other aspect more. |
| 18:47 |
|
fluxionary joined #luanti-dev |
| 19:25 |
MTDiscord |
<herowl> Honestly, I feel like this-> is just clutter most of the times. |
| 19:26 |
MTDiscord |
<herowl> It's not even that annoying to type. |
| 19:27 |
MTDiscord |
<herowl> And I'm not saying to use m_ for public fields that are part of the API... although technically you shouldn't have both member functions and public member variables, as that adds to confusion. |
| 19:27 |
sfan5 |
(might depend on keyboard layout) |
| 19:27 |
MTDiscord |
<herowl> So anyway struct fields are plenty fine without the m_ |
| 19:28 |
MTDiscord |
<herowl> But for private (or protected) member variables, I think m_ is the way to go |
| 19:28 |
MTDiscord |
<herowl> Whenever it appears, you know where it belongs. |
| 19:29 |
MTDiscord |
<josiah_wi> I'm looking at the QWERTY labels on my keys, and "this" does not look very pleasant or unpleasant to type. Incidentally it's significantly easier to type in Dvorak. Coincidence? Who knows. |
| 19:29 |
MTDiscord |
<herowl> Also there's the s_ for static... |
| 19:29 |
MTDiscord |
<josiah_wi> Do we use that in Luanti? I haven't seen it before. |
| 19:30 |
MTDiscord |
<herowl> I don't think we do, I'm not sure we do any static |
| 19:30 |
MTDiscord |
<herowl> My point is, it has the same reasoning behind it: a clear view of side effects |
| 19:33 |
MTDiscord |
<josiah_wi> Well, we don't need clarity in Luanti now, do we? The legacy must live on. |
| 19:37 |
rubenwardy |
uploaded android builds to GH and play store |
| 19:41 |
Krock |
🎉 |
| 23:34 |
|
panwolfram joined #luanti-dev |
