Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Foxfire_: Nov 8, 2010

That seems like a good solution; no variadics in the actual language, only in a not-sucky metaprogramming layer (where the metaprogramming's run time is the overall program's compile time)

# ? Jun 29, 2020 00:52

Adbot: ADBOT LOVES YOU

# ? May 20, 2024 23:27

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

The Rust/C++ approach is really flexible but absolutely horrific for code size and compile time.

# ? Jun 29, 2020 03:29

xtal: Jan 9, 2011; by Fluffdaddy

https://gist.github.com/chrisdone/672efcd784528b7d0b7e17ad9c115292

Dependently typed printf is pretty cool

# ? Jun 29, 2020 03:40

nielsm: Jun 1, 2009

RPATDO_LAMD posted:

At compile time the variadic macro in println!("The cat is {} years old", 7) is transformed by ~~find and replace~~ macro magic into basically something like this (fake code):
And yes, the format string has to be known at compile time.
code:
buf = "The cat is ";
7.printtobuffer(buf);
" years old".printtobuffer(buf);
print(buf);
But with more cleverness to avoid string copying.

So it basically works the same way as C++'s iostream.

And then you have the problem when you want to translate your software. If the strings are broken up at insertion points then translations that require different sentence structure might require recompiling the entire program, instead of just changing some strings data.

# ? Jun 29, 2020 10:25

Xarn: Jun 26, 2015

Ola posted:

If C was made today, I am convinced you could make a type safe, non-variadic "print to console" function that was every bit as a fast as printf. It was a fair mistake made at the time, there is no need to repeat it.

Not in C. In C++ you can make one that is actually significantly faster right now, by abusing compile-time format string processing.

Ola posted:

Which begs the question why do you want to make something that seems like you can, with terrible consequences if you get it wrong, instead of making it easy to use with clearly defined rules that says what you can or can't? The most likely answer is academic circlejerk, with "sins of the fathers" a close runner up. Even if you write C today, you don't have to acknowledge or emulate it in any way, you can write whatever you want as type safe as you should.

PS:

Is there not some limit of n for std::tuple<type 1, type 2, type 3 ... type n> in C++?

I am going to take it from the back. The limit on tuple's type list length is implementation defined. The standard recommends some baseline numbers to support, I think the applicable one here is either [temp.inst] or [temp.param], both of which are 1024.

And the answer to why have variadic functions, the problem here is that people keep conflating C's it-was-a-good-idea-50-years-ago runtime variadics, and newer solutions using their lang's support for variadic type packs, e.g.

C++ code:

template <typename... Args>
int printf(std::string_view format_str, Args&... args) {
    ...
}

knows exactly how many arguments it actually got, what are their types, and can check that against the format string. If you are feeling extra frisky, you can even force compile-time check that the number of args in format string and the number of args you got matches, and precompile the formatters... :v:

# ? Jun 29, 2020 11:12

Xarn: Jun 26, 2015

nielsm posted:

And then you have the problem when you want to translate your software. If the strings are broken up at insertion points then translations that require different sentence structure might require recompiling the entire program, instead of just changing some strings data.

Yeah, not everything needs precompiled formatters. OTOH, I don't think anyone ever translates their log messages.

# ? Jun 29, 2020 11:18

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

I managed to write a routine to check for lines in a file with duplicate identifiers that was quadratic in the number of lines. Good thing I took the time to add a unit test that tries it on real data. 40 seconds in debug to check over a file with just 7,000 lines. Swapped it out for a Dictionary-based approach and it takes 70ms. Good work me from 3 days ago or something

# ? Jul 3, 2020 18:38

Ola: Jul 19, 2004

It would be taking it too far to call this a Coding Horror, it's more like Coding Idiosyncracies And Their Interesting But Perhaps Not Ideal Effects

I can kind of see the point of writing Git commits in imperative form, and I will stick to it if told. But isn't that idea based on some git master (perhaps an angry Finnish one) merging in the single commit in the same terminal environment it was made, performing the imperative action by doing so? But I've never seen that actually happen. It's more like this is a pull request in a web interface with one or a million commits, many of which where pushed just to save game before boarding a plane or whatever, most of the commit messages are just "wip" and "woops" but the PR text actually contains a well written summary and a link to the project management ticket. And once it's approved by someone else in a code review, the person who wrote it does the merging. Still, fair play if I work with you and you want it like that. Then I'll write it like that.

Also, I can definitely see the usefulness of generating patch notes from carefully written commits.

However, I'm definitely not having patch notes on the imperative form. In doesn't make any sense. Are the patch notes promising me things they will do in the next patch? Or is it some sort of open source awareness stunt, trying to get me to contribute by giving me a list of stuff to fix it myself?

tl;dr write git commit -m "fixed bug gently caress you"

# ? Jul 4, 2020 19:55

Adhemar: Jan 21, 2004; Kellner, da ist ein scheussliches Biest in meiner Suppe.

You can write whatever you want in your local commits, as long as you clean it up and squash before you put up your CR.

# ? Jul 4, 2020 20:01

Ola: Jul 19, 2004

Adhemar posted:

You can write whatever you want in your local commits, as long as you clean it up and squash before you put up your CR.

But "what you want" and "clean it up" depends on some particular policy. Maybe 500 "wip" commits is ok in many companies. The particular policy I'm getting at is the dogma of imperative form.

# ? Jul 4, 2020 20:05

Adhemar: Jan 21, 2004; Kellner, da ist ein scheussliches Biest in meiner Suppe.

Ola posted:

But "what you want" and "clean it up" depends on some particular policy. Maybe 500 "wip" commits is ok in many companies. The particular policy I'm getting at is the dogma of imperative form.

�What you want� is literally whatever you want because nobody else ever has to see it (your local commits). The cleaned version does indeed vary wildly in different companies. I�ve never heard of this imperative form thing, that seems overly pedantic.

# ? Jul 4, 2020 20:19

Vanadium: Jan 8, 2005

idk how you can be against variadic templates in C++. Everybody was doing horrible hard to read bullshit to pretend to have varargs anyway, first-class support just made all of that less awful. If I never have to see a function copy+pasted 17 times to cope with all amounts of arguments it might be called with ever again, I'll die happy.

Meanwhile try scrolling through the docs for tuples in rust, https://doc.rust-lang.org/std/primitive.tuple.html, or this bullshit that is partially ifdef'd to hide its shame from autogenerated docs: http://hackage.haskell.org/package/base-4.1.0.0/docs/src/Data-Tuple.html

# ? Jul 4, 2020 20:20

Ola: Jul 19, 2004

Adhemar posted:

I�ve never heard of this imperative form thing, that seems overly pedantic.

Ah, well there we go, that's the misunderstanding. Some are super strict on this, many have heard about it and just accept it as the done thing. And as the screenshot illustrates, the Notepad++ team seems to do it and then generate patch notes from it.

edit, example:

https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53

quote:

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space. Use a hanging indent.

Wrap it to 72 characters, strictly imperative form...? Sounds suspiciously like something a particularly feisty Finnish penguin would come up with.

# ? Jul 4, 2020 20:21

Ola: Jul 19, 2004

Vanadium posted:

idk how you can be against variadic templates in C++. Everybody was doing horrible hard to read bullshit to pretend to have varargs anyway, first-class support just made all of that less awful. If I never have to see a function copy+pasted 17 times to cope with all amounts of arguments it might be called with ever again, I'll die happy.

Meanwhile try scrolling through the docs for tuples in rust, https://doc.rust-lang.org/std/primitive.tuple.html, or this bullshit that is partially ifdef'd to hide its shame from autogenerated docs: http://hackage.haskell.org/package/base-4.1.0.0/docs/src/Data-Tuple.html

This is probably aimed at me, but I guess I haven't scrolled as many copy pasted things as you therefore I do not have the same opinion. The generated docs and definitions are useless, but do you even need them once you learn that a tuple is some types in paranthesis with comma between and sadly the native one has a hard limit at 17 or whatever? It's not like you go diving in there looking for the subtle particularities which kick in when you go from 14 to 15 types.

# ? Jul 4, 2020 20:29

Vanadium: Jan 8, 2005

Edit: ^^^ not aimed at you in particular, I'm just surprised at the consensus itt. Yeah, it's not like the docs are particularly the problem, they just demonstrate how awkward it gets if you try to write anything flexible enough to support variable amounts of values or whatever.

From the people that brought you arrays that can only be equal or unequal to other arrays up to length 32:

code:

fn main() {
    // good, perfectly reasonable code a normal person would write
    let ok = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31];
    println!("{}", ok == ok);

    // a blight upon the codebase, escaped from the sick mind of a C++ programmer 
    let welp = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32];
    println!("{}", welp == welp); // this doesnt compile
    
}

Vanadium fucked around with this message at 20:32 on Jul 4, 2020

# ? Jul 4, 2020 20:29

Xarn: Jun 26, 2015

Funnily enough, Linus is not a big proponent of 72 char limit on code, but things like GitHub and GitLab UI start breaking if the first line of your commit msg is overly long.

---e----

In regards to variadic, I am much more mad about having to copy paste code for multiple template args instead of being able to define a variadic type pack, than I am about low limit on its size... I think the only place where I wrote code using variadic type pack with more than 10 types was a compile-time test for that template :v:

Xarn fucked around with this message at 20:38 on Jul 4, 2020

# ? Jul 4, 2020 20:35

Ola: Jul 19, 2004

Copy pasting code is the easiest work I can do. The common variant:

code:

public int Sum(int firstArgument)
{
	return firstArgument;
}


public int Sum(int firstArgument, int secondArgument)
{
	return firstArgument + secondArgument;
}

public int Sum(int firstArgument, int secondArgument, int thirdArgument)
{
	return firstArgument + secondArgument + thirdArgument;
}

It's easy to write, easy to read... what's the problem? Doesn't scale? It's more interesting to ask if it's useful to have the same function take a whole bunch of different arguments and behave differently depending on the number of arguments. Do you not like to be limited by the number of arguments? Well then simply:

code:

public int Sum (int singleArgument)
{
	return Sum(new int[] {singleArgument});
}

public int Sum (int[] manyArguments)
{
	return MagicComplexArraySum(manyArguments);
}

Is it different, complex logic depending on different cases? Maybe the function shouldn't even have the same name then. Or maybe they can build on each other like:

code:

public Thing GiveMeTheThing()
{
	return MakeThing(defaultThingParameter);
}

public Thing GiveMeTheThing(ThingParameter param)
{
	return MakeThing(param);
}

public Thing GiveMeTheThing(ThingParameter param, WeirdThingCase weird)
{
	return MakeThing(ResolveWeirdCaseParameters(param,weird));
}

//etc...

It certainly doesn't seem better to create complex, bug-prone language structures just for the sake of programmer "freedom" in parameter numbers or saving a few minutes of copy paste activity. And for others maintaining it, it's super easy to read and navigate copy pasted overloads sorted in ascending order of argument numbers. As those more versed in C responded (I am not versed at all, just defaulted to C# which I am writing now), it was perhaps an innate feature of the language and a useful decision at the time but it seems wrong to stick to that idea when we live in the now. And while I have no experience in C and don't write C++ at work, I think that what I've written now applies to modern C++. If you go for variadic templates to save time calling functions but end up getting problems, I am guessing that the time you could have spent copy pasting overloads will be less than 1/10th of troubleshooting the first variadic bug.

Am I naive? What case does variadic behaviour solve in the current C++ world with a worthwhile tradeoff, given that he code is maintained by people who are not all C++ wizards?

# ? Jul 4, 2020 21:39

Xarn: Jun 26, 2015

I find your lack of imagination... disturbing. :v:

I am going to use an example from a library I maintain, specifically the part that provides generic Hamcrest-style matchers for assertions. After recent changes to take full advantage of variadic templates, the usage looks something like this

C++ code:

        REQUIRE_THAT(some_vec, SizeIs(2) && Contains(2));

What it does is that it first constructs a generic SizeIs matcher, then a generic Contains matcher and then combines them into a generic AllOf matcher. The reason why I am saying that the individual matchers are generic is that they interoperate with any type that quacks like a range -- as an example, this is how the SizeIs matcher is implemented:

C++ code:

        class HasSizeMatcher final : public MatcherGenericBase {
            std::size_t m_target_size;

        public:
            explicit HasSizeMatcher(std::size_t target_size):
                m_target_size(target_size)
            {}

            template <typename RangeLike>
            bool match(RangeLike&& rng) const {
                using std::size;
                return size(rng) == m_target_size;
            }
        };

(I omitted some things that are not needed for the matching itself)

So far so good, the type even has a base class that could in theory be used to hold it in a single-type container... except that loses access to match, because you obviously cannot have templated virtual member functions. So, if you are to store multiple matchers like this (e.g. when you are constructing a generic MatchAll matcher), and use them to do matching, you have to keep around their actual types. That is where variadic template packs come in. The following is the implementation of MatchAll

C++ code:

        template<typename... MatcherTs>
        struct MatchAllOfGeneric final : MatcherGenericBase {
            std::array<void const*, sizeof...(MatcherTs)> m_matchers;

            MatchAllOfGeneric(MatcherTs const&... matchers) : m_matchers{ {std::addressof(matchers)...} } {}

            template<typename Arg>
            bool match(Arg&& arg) const {
                return match_all_of<MatcherTs...>(arg, m_matchers, std::index_sequence_for<MatcherTs...>{});
            }

            std::string describe() const override {
                return describe_multi_matcher<MatcherTs...>(" and "_sr, m_matchers, std::index_sequence_for<MatcherTs...>{});
            }

            //! Avoids type nesting for `GenericAllOf && some matcher` case
            // constraint to check for generic matchers omited
            template<typename MatcherRHS>
            friend
            MatchAllOfGeneric<MatcherTs..., MatcherRHS> operator && (
                    MatchAllOfGeneric<MatcherTs...>&& lhs,
                    MatcherRHS const& rhs) {
                return MatchAllOfGeneric<MatcherTs..., MatcherRHS>{array_cat(std::move(lhs.m_matchers), static_cast<void const*>(&rhs))};
            }
            
            // ... Other type simplifying overloads omitted ...
        };

And this is what the free && operator looks like:

C++ code:

    // constraint to check for generic matchers omited
    template<typename MatcherLHS, typename MatcherRHS>
    MatchAllOfGeneric<MatcherLHS, MatcherRHS> && (MatcherLHS const& lhs, MatcherRHS const& rhs) {
        return { lhs, rhs };
    }

The above code allows you to create an arbitrarily (up to your implementation's limits) complex MatchAll matchers from very simple syntax. Together with similar code for || and !, this greatly simplifies both the usage of the provided matchers (because they can be generic over different types), and users will have it easier to write their own matchers (for the same reasons).

Now, could I just stamp out tons and tons and tons of overloads to handle all this? Yes. But the tradeoffs for that are worse compilation times and worse maintenance experience later on -- imagine deciding to improve describe's output, and then having to account for subtle differences between the 30 different overloads :suicide:

Are these tradeoffs potentially worth it? Maybe. Is it worth it because someone is afraid of variadic types? Definitely not.

And as to maintenance by others... the whole point of libraries and abstractions is that the hard parts can be written be people familiar with the domain, while the users do not need to understand that complexity. :shrug:

# ? Jul 4, 2020 22:51

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

The only "objective" argument for writing commit messages in the imperative tense is that it's typically the shortest form so you can fit more words in the subject line. It's something that doesn't matter very much, but there's also no reason not to just follow what the tool recommends.

# ? Jul 4, 2020 22:52

Xarn: Jun 26, 2015

Other things variadics are used for are things like generic factory functions (make_unique, make_optional, (j)thread), and doing terrible things to your compiler for profit (precompiling regexes, format strings).

# ? Jul 4, 2020 22:53

Xarn: Jun 26, 2015

Plorkyeran posted:

The only "objective" argument for writing commit messages in the imperative tense is that it's typically the shortest form so you can fit more words in the subject line. It's something that doesn't matter very much, but there's also no reason not to just follow what the tool recommends.

Yeah, I tend to write in 3rd person ("Fixes bug caused by unexpected interaction between foos and bars"), but when I run out of characters for summary and have to shorten it, I usually end up at imperative tense to save those precious characters.

# ? Jul 4, 2020 22:55

QuarkJets: Sep 8, 2008

What's it called when a c++ function has an argument with a default value? I like and often use that kind of variadicity. Obviously not the same as what everyone else is talking about, though

# ? Jul 4, 2020 23:11

Ola: Jul 19, 2004

Xarn posted:

MatchAll!

Thank you, very interesting example! If it's easy to use and works well, obviously no problems. But the topic did come up as variadic being harder to handle than non-variadic. And the case you illustrate doesn't have to be variadic to solve the usefulness of having an arbitrary number of matchers: A single matcher can be a list of one matcher. The && or || or other operators concatenate lists of matchers according to appropriate rules, then return lists of matchers. Obviously these get evaluated before the function call. The function called which deals with matching takes two arguments, something to be matched and a list of matchers. No need for arbitrary amounts of arguments, no need for variadics.

# ? Jul 4, 2020 23:46

Absurd Alhazred: Mar 27, 2010; by Athanatos

QuarkJets posted:

What's it called when a c++ function has an argument with a default value? I like and often use that kind of variadicity. Obviously not the same as what everyone else is talking about, though

I think that under the hood it's essentially the same as overloading.

# ? Jul 4, 2020 23:50

zergstain: Dec 15, 2005

Xarn posted:

And this is what the free && operator looks like:

C++ code:

    // constraint to check for generic matchers omited
    template<typename MatcherLHS, typename MatcherRHS>
    MatchAllOfGeneric<MatcherLHS, MatcherRHS> && (MatcherLHS const& lhs, MatcherRHS const& rhs) {
        return { lhs, rhs };
    }

Is that some new syntax? It looks like you are declaring a function called &&() as opposed to operator&&().

# ? Jul 4, 2020 23:56

Space Gopher: Jul 31, 2006; BLITHERING IDIOT AND HARDCORE DURIAN APOLOGIST. LET ME TELL YOU WHY THIS SHIT DON'T STINK EVEN THOUGH WE ALL KNOW IT DOES BECAUSE I'M SUPER CULTURED.

Ola posted:

Am I naive? What case does variadic behaviour solve in the current C++ world with a worthwhile tradeoff, given that he code is maintained by people who are not all C++ wizards?

Are you arguing against variadic functions in general, or C++'s specific implementation?

In general, they can be a useful way to pass a list of arguments determined at compile time, for something like printf or a logging function. Why copy-paste (and run the risk of errors buried in your pile of almost-but-not-quite identical logic) when you don't have to?

C++'s implementation is ugly because there's no way to express "some type, I don't care what it is" without templates, and that's a common case for variadic functions. Java, C#, and most other modern OO languages handle variadic functions in a clean, type-safe way by just giving you an array of params, that can be of the base object type or anything else you want.

# ? Jul 5, 2020 00:06

Ola: Jul 19, 2004

Plorkyeran posted:

The only "objective" argument for writing commit messages in the imperative tense is that it's typically the shortest form so you can fit more words in the subject line. It's something that doesn't matter very much, but there's also no reason not to just follow what the tool recommends.

This and other character limit arguments begs the question why there are character limits at all. What was the original limitation Linus based it on? When I write commits now in VS Code, it warns me when I get near and when I cross it. But when I keep writing it shuts up. I push, all my characters are intact on Github. In VS I think it doesn't even warn me. What does the character limit do, who or what is it for? There is obviously nothing bandwidth wise limiting it in any aspect, as you can send bagillions of bytes of code along with your limited commit message. Is it just the emperor penguin deciding that 72 bytes should be enough for anyone?

*googles*

https://www.midori-global.com/blog/2018/04/02/git-50-72-rule

Yes, it is the emperor penguin.

quote:

What is the 50/72 rule?

50/72 rule is a commonly accepted best practice for formatting commit messages in Git. This is also considerable for other version control systems, as it is absolutely not tied to Git. It was originally "invented" and promoted by the Linux Kernel team, and gained universal popularity later.

Now that is a coding horror. It seems more like tyrannical behavior rather than promoting good processes, trying to quench upstarts who can't quite stick to the "make one change" dogma. If you babble, can't quite put it to me in 72 characters, denied. Any Git implementation I've used seems to agree because there's no actual character limit, just a GUI warning. There is obviously no good reason to say another organization outside the Linux kernel team should limit themselves to any number of characters. What if the link to my project management tool is always 73 characters long? And there is obviously no universal rule that says ideas are always sufficiently explained in 72 characters or less.

# ? Jul 5, 2020 00:09

csammis: Aug 26, 2003; Mental Institution

I think you missed the �arbitrary number of 72 character-wide lines� part. No one�s saying you�re limited to exactly 72 characters after a 50 character subject line.

It�s still a stupid loving rule.

# ? Jul 5, 2020 00:18

zergstain: Dec 15, 2005

Why 72? I thought 80 was the width of those dumb terminals from the 1970s.

# ? Jul 5, 2020 00:26

Ola: Jul 19, 2004

Space Gopher posted:

Are you arguing against variadic functions in general, or C++'s specific implementation?

In general, they can be a useful way to pass a list of arguments determined at compile time, for something like printf or a logging function. Why copy-paste (and run the risk of errors buried in your pile of almost-but-not-quite identical logic) when you don't have to?

C++'s implementation is ugly because there's no way to express "some type, I don't care what it is" without templates, and that's a common case for variadic functions. Java, C#, and most other modern OO languages handle variadic functions in a clean, type-safe way by just giving you an array of params, that can be of the base object type or anything else you want.

I'm arguing against the idea of an arbitrary number of function arguments being better than a finite number of arguments. The bolded bit is not a problem. A list of something is one argument. Although in Bash, it seems like you give an "arbitrary list", but it's an arbitrary input which turns into a single list of ok inputs or a crash. It's an arbitrary amount of arguments I don't like, and the discussion got started by people having had trouble with variadic implementations and maintenance. It does seem like there is no modern need for variadics, other than to support old structures where it was more like variadics weren't explicitly banned rather than actively supported. Something I alluded to earlier was the academic circlejerk, that is always a factor unfortunately. The theoretical scene might have grand ideas about how amazing variadics are and push for their support in a language, without being interested in the fact that it might not be very useful to anyone actually programming something.

# ? Jul 5, 2020 00:30

RPATDO_LAMD: Mar 22, 2013; 🐘🪠🍆

Space Gopher posted:

Are you arguing against variadic functions in general, or C++'s specific implementation?

In general, they can be a useful way to pass a list of arguments determined at compile time, for something like printf or a logging function. Why copy-paste (and run the risk of errors buried in your pile of almost-but-not-quite identical logic) when you don't have to?

C++'s implementation is ugly because there's no way to express "some type, I don't care what it is" without templates, and that's a common case for variadic functions. Java, C#, and most other modern OO languages handle variadic functions in a clean, type-safe way by just giving you an array of params, that can be of the base object type or anything else you want.

Accepting an array of base-object pointers and attempting to cast them to the appropriate type at runtime sounds like the exact opposite of type-safe.
The only advantage of that over C-style printf is that you get an actual exception when it fails at runtime instead of garbage data or a crash.

# ? Jul 5, 2020 00:35

Zopotantor: Feb 24, 2013; ...und ist er drin dann lassen wir ihn niemals wieder raus...

zergstain posted:

Why 72? I thought 80 was the width of those dumb terminals from the 1970s.

it's worse than you think

# ? Jul 5, 2020 00:38

Ola: Jul 19, 2004

csammis posted:

I think you missed the �arbitrary number of 72 character-wide lines� part.

Yeah, I definitely missed that part, because I wasn't rubbing my fingers and sniffing the finer grains of the stupid bullshit.

"Ideal values"

# ? Jul 5, 2020 00:40

Absurd Alhazred: Mar 27, 2010; by Athanatos

The only problem I have with variadic templates in C++ is that it introduces a separate foreach notation instead of using the one they've already established.

# ? Jul 5, 2020 00:41

Ola: Jul 19, 2004

Zopotantor posted:

it's worse than you think

Incredible computer scientific foresight to accommodate the Linux kernel community's idea of an ideal commit message length value.

# ? Jul 5, 2020 00:45

Vanadium: Jan 8, 2005

zergstain posted:

Why 72? I thought 80 was the width of those dumb terminals from the 1970s.

Probably a combination of git log indenting (but only by... 4 spaces?) and allowing for some amount of "> " when quoting commit messages in emails.

# ? Jul 5, 2020 01:43

VikingofRock: Aug 24, 2008

Ola posted:

Incredible computer scientific foresight to accommodate the Linux kernel community's idea of an ideal commit message length value.

Wasn't git created for Linux kernel development? It kind of makes sense from that perspective.

# ? Jul 5, 2020 03:23

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

The fart-huffing bit is declaring that the "ideal" limit is shorter than about half of the commit messages that your project already uses.

# ? Jul 5, 2020 04:34

taqueso: Mar 8, 2004

Jabor posted:

The fart-huffing bit is declaring that the "ideal" limit is shorter than about half of the commit messages that your project already uses.

make a tool that does this, a snazzy website, and sell this poo poo like crazy as a consultant

# ? Jul 5, 2020 04:35

Adbot: ADBOT LOVES YOU

# ? May 20, 2024 23:27

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Ola posted:

This and other character limit arguments begs the question why there are character limits at all. What was the original limitation Linus based it on? When I write commits now in VS Code, it warns me when I get near and when I cross it. But when I keep writing it shuts up. I push, all my characters are intact on Github. In VS I think it doesn't even warn me. What does the character limit do, who or what is it for? There is obviously nothing bandwidth wise limiting it in any aspect, as you can send bagillions of bytes of code along with your limited commit message. Is it just the emperor penguin deciding that 72 bytes should be enough for anyone?

I think the suggested limit of 50 characters for the subject line is overly short (especially when you're doing things like putting ticket numbers in the subject), but if you're going way over it then you've probably failed to actually write a subject line and should put most of that in the body.

I don't really see a reason to give a gently caress about what the line character limit for the body is. I just write some text then hit the word wrap button in my text editor.

# ? Jul 5, 2020 05:46

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »