crazyfactory/php-sniffs

can't override the value of Generic.Files.LineLength.TooLong

Closed this issue ยท 8 comments

Context

For some cases we really want to have more than 120 characters (considering today's computers, 200 should be fine). I tried to add the following to phpcs.xml

<rule ref="Generic.Files.LineLength.TooLong">
        <properties>
            <property name="lineLimit" value="200" />
            <property name="absoluteLineLimit" value="200" />
        </properties>
</rule>

Expected:

to not complain for any lines lesser than 200 characters,

Actual:

complains for any lines more than 120 characters

PS: I might have been wrong, please verify it before considering this a bug.

Never mind, the usage was wrong, I used the following snippet and it worked perfectly:

<rule ref="Generic.Files.LineLength">
    <properties>
        <property name="lineLimit" value="200"/>
        <property name="absoluteLineLimit" value="200"/>
    </properties>
</rule>

Closing

we will definetely not allow that in any project here though :D it's less about the screen size, but more about human perception and code comparison... so having two files next to each other in a nice readable size and probably a sidebar should never cause any hassle ^^

really? so we'll always have 120 lines of code in ERP? that's a lot lesser than I hoped ๐Ÿ™‚ , I couldn't even refactor a lot of them even at 200, there are lines with more than 1000 characters ๐Ÿ˜„

i believe our limit is 140 right now.

The classical setting is 80 i believe to accommodate older CLI terminals. That's definitely not necessary.

Now we choose a limit not because of the technical limitation, but purely for code style reasons to enforce good readability ^_^

so on a full HD screen you can do roughly this:
image

and in onlinetools like github you don't have to scroll around vertically too much. (i believe github shows 120 without scrolling).

it's a similar issue as to why lengthy files are a bad standard because maintaining them is a pain.

IMHO lengthy lines are a bigger problem as git is heavily line focused when it comes to commits/blames etc. so multilineing stuff has additional advantages.

okay, understood ๐Ÿ™‚

ok :D

that set aside... it's still strange that it actually doesn't work hehe. Still hardly worth a fix hmm

maybe the rule I used wasn't correct, that's a possibility, anyway, the other rule is working, so don't need a fix ๐Ÿ˜„