Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The library also uses some absurdly long identifiers which are bound to clutter your code one way or another. To iterate a binary tree, use

while(lfds710_btree_au_get_by_absolute_position_and_then_by_relative_position(state, &element, LFDS710_BTREE_AU_SMALLEST_IN_TREE, LFDS710_BTREE_AU_INORDER_WALK_FROM_SMALLEST_TO_LARGEST))

It's not going to be possible to remember what names to use when you need to iterate. Or, take the initialization routine. You first call

lfds710_btree_au_init_valid_on_current_logical_core( &state, key_compare_function, LFDS710_BTREE_AU_EXISTING_KEY_FAIL, NULL );

on one core, which is perhaps reasonable, but then you call

LFDS710_MISC_MAKE_VALID_ON_CURRENT_LOGICAL_CORE_INITS_COMPLETED_BEFORE_NOW_ON_ANY_OTHER_LOGICAL_CORE()

on other cores. That is one hell of a #define, and it's not even clear from the name what it's doing. It seems like "LFDS710_MISC_SYNC_INITS" or something along those lines would be clearer and easier to remember.



Holy shit! That's 71 characters, which leaves you 9 characters for your code. 4 of that goes to indentation, 3 of that goes to (); and you have 2 characters left for the parameters before you break the 80 character limit. That's horrifying.


OTOH, you do know exactly what it does, without having to read any docs.

I am of course open to suggestions for improvement.


Encourage the adoption of a line-width that is longer than ancient terminals (at least it isn't 40 cols across).

Also I'm much less concerned with absolute line width in my own code than I am with indentation steps or number of arguments something takes without flowing on to multiple lines.


Yes, some of the identifiers are very long. The aim was to make the APIs self-explanatory. It should be possible to read an API and know what it does. It's challanging to explain an inorder walk, and its direction, in a shorter form.

The goal of course is for all identifiers to be as short as possible.


What about replacing FROM_SMALLEST_TO_LARGEST with ASCENDING?


That could work. ASCENDING and DESCENDING. I'll think it over (in the morning - I'm about comatose right now).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: