lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 2017-06-14 03:54 PM, David Goehrig wrote:
I have some code formatting scripts that enforce tab only (and warn if you go over 3 levels of indentation). The scripts also do some basic heuristics concerning function length, number of static calls, dead code, and generate dot format static call graphs. If I get some time, I'll try to package them up and release them on <>.

<tab><tab>local function uh(oops, something, tells, me, this, is, a, giant,

Have fun getting that aligned.

(as opposed to mixed tabs+spaces)

I have found going LCD for your solution is always a bad idea, and you need tooling to enforce such policy. I tend to run these scripts as commit hooks, and it solves the git hash nonsense without wasting developer time.

As I get older, and my eyes grow weaker, I find the spaces camp to be a major human interface problem. I can always configure my editor of choice to make tabs legible size (I prefer 8em at 16pt), but can't do the same with spaces. It becomes a serious quality of life issue for some developers.


On Jun 14, 2017 12:59 PM, "Charles Heywood" < <>> wrote:

    Project level editorconfig files would help with that. I
    personally use them with no complaints

    On Wed, Jun 14, 2017, 11:57 Enrico Colombini <
    <>> wrote:

        On 14-Jun-17 17:29, Sergey Rozhenko wrote:
        > For me it's crazy that so many people to this day use spaces
        instead of
        > tabs. Using tabs helps avoid all these issues of different
        > and adds only one: indentation in text from the Internet
        always has to
        > be fixed rather than in half the cases, not that it really

        Many, many years ago I used tabs. I quit when I began to port
        code among
        different editors, environments and people: it was a big,
        unreadable mess.

        Now I only use spaces [1]: what I see is what I see, everywhere.

        [1] apart from makefiles, of course.


-- -- Ryan < <>>
    Software Developer / System Administrator

Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.