Re: [libvirt] proposal: file renames for consistency
On Wed, Aug 22, 2018 at 03:25:31PM -0500, Eric Blake wrote: > We have an inconsistent mix of multi-word file names that use dash vs. > underscore to separate those words. > > $ git ls-files '**/*_*' | wc >24972497 146485 > $ git ls-files '**/*-*' | wc >81478147 26 > > Some of those are overlaps (meaning we can't make up our minds), such as: > docs/api_extension/0001-add-to-xml.patch I think its important to look at the directory breakdown, as we have a very uneven file layout: build-aux/ 5 docs/ 225 examples/ 65 gnulib/ 2 include/ 18 m4/ 104 po/ 103 src/ 881 tests/ 8309 tools/ 80 Essentially all the interesting source code is under src/ since we got rid of the daemon/ directory, with a little in tools. The majority of files are in tests/, as example data input files. If we compare '_' vs '-' for the source code, the picture is very different: $ git ls-files '**/*_*' | grep src/ | wc -l 460 $ git ls-files '**/*-*' | grep src/ | wc -l 46 so I have a very hard time justifying that we should rename all our src files to use '-', when the precedent is 10:1 in favour of '_'. In the tests directory things are more complicated, because we require some precise filenames. For example, we have a whole set of files that are replicating the Linux sysfs file structure and those must use _ because Linux used _ in sysfs. We have other files which include the architecture name, and so must be "x86_64", not "x86-64". This prevents us removing almost all use of '_' in tests/, with only a few exceptions. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] proposal: file renames for consistency
On Wed, 2018-08-22 at 15:25 -0500, Eric Blake wrote: [...] > So, would anyone like a beginner's project of consistently renaming > files, and/or would anyone object if I submitted some patches along > those lines? I like the idea. Consistency FTW! After the switch, we should make sure syntax-check complains loudly if file names containing underscores are found in the repository in order to avoid them creeping back in over time. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] proposal: file renames for consistency
We have an inconsistent mix of multi-word file names that use dash vs. underscore to separate those words. $ git ls-files '**/*_*' | wc 24972497 146485 $ git ls-files '**/*-*' | wc 81478147 26 Some of those are overlaps (meaning we can't make up our minds), such as: docs/api_extension/0001-add-to-xml.patch However, my personal preference is to use dash everywhere (or at least on all the .[ch] files), for at least several reasons: 1. dash is easier to type (at least on US keyboards), as it does not require the shift key [I find it easier to edit files in tools/ than in src/qemu/ for example, because I don't have to worry about shift] 2. include/ uses only dash, not underscore; if our public interface favors that spelling, our internal files should too 3. underscore is easier to miss visually when other markup like underline is being applied (for example, when viewing the git repository online and hovering over a filename). Granted, you can still often tell that an underscore is present vs. a space (or in general, realize that we avoid spaces in file names in our git tree, so it must be an underscore); but I still find dash much easier to pick out. Since git rename detection does a good job at tracking history by content over file renames, a mass rename wouldn't even be that invasive to git archaeology or patch backporting. If you're worried about finger memory typing the wrong form, but you use bash, it's possible to configure bash to treat '-' and '_' interchangeably during TAB-completion (similar to case insensitive tab completion), which reduces some of the pain, but it doesn't solve everything. So, would anyone like a beginner's project of consistently renaming files, and/or would anyone object if I submitted some patches along those lines? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
