As mentioned here in the item on vertical alignment of conceptually similar concepts:
Aim to align statement parts that are conceptually similar. It allows the reader to quickly see how they’re different. E.g. in this code it’s immediately clear that the two parts call the same code with different parameter orders.
if self.store.stretch_dir==0: x = stretch_cv(x, self.store.stretch, 0)
else: x = stretch_cv(x, 0, self.store.stretch)
I’m appreciating the abbreviations doc.
I’d like to propose a few changes/additions:
I. that we have a vertically aligned abbreviations for anything related to train/validation/test.
Currently the doc has:
train trn trn_ds
validation val val_ds
can we add one more?
test tst tst_ds
Also, can we start using similar in structure variable names in the notebooks:
df_val
df_trn
df_tst
(perhaps these could go into the abbr doc too?)
currently used convention of:
df = ...
df_test = ...
doesn’t align well and its very inconsistent in general.
II. As you can see we have df_trn
and trn_ds
- should we have a consistency there as well? probably purpose first and type second?
Should we switch to df_trn
and ds_trn
. i.e. renaming *_ds
to ds_*
. (and change abbr.md)
But then I see there are many other vars that currently use type_purpose convention, as in: opt_fn, init_fn, reg_fn
. If it’s more readable it’s fine, then can we change df_*
to *_df
? so trn_df, tst_df, val_df
?
I think one important consideration to take into account here is the use of TAB completion. In the long run, Is it better to have the variable start with the type: val_[TAB]
, or purpose df_[TAB]
to type less?
p.s. markup rendering messes up code formatting if using 1) 2) items, so I used Romans to separate the issues
Thank you!