I generally prefer using explicit names over abbreviations. Benefits of abbreviations are small, while there are good reasons to avoid them (ambiguity, readability, error susceptibility, etc). It’s the old “code is only written once, but read many times” thing that we should keep in mind.
This concrete suggestion is about (screen-)area variables (ScrArea struct), usually abbreviated with sa, and (area-)region variables (ARegion struct), usually ar.
When I started getting into Blender coding, I was fooled into taking ar as area all the time, (area)-region would’ve been correct though. Still to this day, this may happen to me when caffeine level is running low. I’m for sure not the only one facing this.
I suggest the following convention change for variable names:
Type
Old name
Proposed name
ScrArea
sa
area
ARegion
ar
region
I’m not suggesting to do big cleanup commits, just that we start using the proposed names from now on.
Am so used to these so I personally don’t mind how it is now. But agree ar reads more like area than region.
So am not against this.
On a related note - am not keen to apply this rule more generally. Am quite happy to keep wm for window-manager, ob for object, quat for quaternion.
I’ve noticed in 2.8 there is some preference for longer names (eg: wm_workspace_configuration_file_write_exec, why not use the term *_config_* ? it’s unambiguous and a well understood abbreviation).
When working on the manipulator branch, I got tired typing in “manipulator” (autocomplete doesn’t always kick in when you want). I temporarily bound the word to a key-shortcut, but this isn’t a great solution for general development.
eg: WM_manipulator_group_type_add and wmManipulator *manipulator so I opted for short names (wmManipulator *mpr).
In C the type information is always close by, so as long as the names are recognizable, don’t have collisions or cause for mixing up variables, I find short names helpful, especially since you often want to clarify with *_src, *_dst, *_iter, *_removed. It can get a bit too much to use these long names all over.
I’ve also gotten so used to it that I don’t even think of it anymore. Whenever I talk to others about those types I always use “area” and “region” so that would match better. Making a change like this can sometimes be annoying because it really pollutes the git annotation and it’s in almost all ui code files, but maybe better to deal with it in a big leap like 2.8.
I rather not start a different naming convention while leaving existing functions unchanged, then it becomes more and more inconsistent over time. Consistent naming helps readability/searchability too.
ar should have been named differently, but personally I don’t think it’s a big enough problem to deal with the disruption.
I agree with Brecht on rather not starting a mixed convention.
Also, feel that “ar” isn’t so awful since the declaration is right there in the function staring at you. Maybe you think “area” the first time you see it, but don’t you then look at the declaration to confirm your guess?
IMO, it’s really not that bad - but then again, I’ve been used to this for 10+ years now
On the larger topic of abbreviations vs long_fully_typed_out_names, I’m in favour of the use of abbreviations in general, especially when you’re repeatedly using something so often that it’s a pain typing/reading long named cruft to get to the point.
Also, there’s the line length/wrapping problem - longer names = more code needs to end up getting wrapped.
