[libvirt] proposal: file renames for consistency

Eric Blake eblake at redhat.com
Wed Aug 22 20:25:31 UTC 2018


We have an inconsistent mix of multi-word file names that use dash vs. 
underscore to separate those words.

$ git ls-files '**/*_*' | wc
    2497    2497  146485
$ git ls-files '**/*-*' | wc
    8147    8147  444426

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




More information about the libvir-list mailing list