AstuteCat posted:

code:

    /// <summary>ToJson.</summary>
    /// <returns>string</returns>
    /// <param name="config">The config variables.</param>
    public string JsonToString(IOpserveConfiguration config)
    {
      this.propertyName = null;
      var ret = JsonConvert.SerializeObject(this, Formatting.None, config.SerialiserSettings);

      return ret;
    }

I wasn't going to post this but this is the second time that I have had this exact piece of code appear in a pull request, the first of which I rejected with a strong explanation that mutating the internal state of an object before returning a string representation of it is ah, not going to be fun for anyone/anything wanting to access that property afterwards.

Hammerite posted:

What kind of communities do you have to mix in in order for this reasoning to appear sensible on any level

"I was going to call my new software library something innocuous, so that we could all get on with productive work. But then it occurred to me that it's important to trigger the cucks on occasion"

Jabor posted:

Odds are he wanted to name it a racial slur to begin with, and then went reaching around for some plausible deniability.

quote:

Also I've always beleived that programmers are beyond the politics, sexism

repiv posted:

Dumb Lowtax posted:

I hope I'm not like that. Some of my students complain that I use a very "horizontal" coding style. Indeed I take a lot of measures to save lines of code, and word wrap being OFF is *required* for reading it, but:

- I still don't skimp on descriptive variable names and write them as entire phrases in underscore_case
- I try not to leave single tokens on lines (like open braces), but rather than stuffing them onto the end of the previous line and killing vertical bracket matching, I use Horstmann style indentation and just do open brace, space, first line of code
- It's done in a way that maximizes how many similar tokens line up vertically, so repetition stands out and you end up having to read less
- I use two spaces for indents to save space, but to still keep things readable I increase indentation twice for each code block: once for the code itself, and once again for the curly braces, that way the curly braces (and hence the structure of the code) stand out that much more
- My main tool of eliminating lines of code is still eliminating complexity, not deleting line breaks, and I'll still frequently add line breaks to a one liner if it gets too gross

My longest lines are over 200 characters, which goes well of the screen on an older laptop, but I do have an older laptop so it's not like I'm subjecting people to something that I personally don't have to deal with. Also, due to carefully lining up repetitive information and curly braces, all the information about the *structure* of the code will appear towards the left hand side of the screen, so it's pretty readable if you're just scanning down the left side and I rarely find myself having to reach for the horizontal scroll bar to read the rest of a line. So turning word wrap on to always see the remaining boring bits of those lines while killing vertical alignment would not be worth it at all.

If a line of code I wrote is that long it's usually because it's uninteresting, old, solidified, tested, and unnecessary for understanding the rest of the lines. And if there's multiple lines around it that share a lot of parts I'll be sure to vertically align those parts.

code:

  { let button = parent.appendChild( Object.assign( document.createElement( "button" ), { default_color: color, textContent: "("+shortcut_combination+") "+description, style: "background-color:" + color } ) ),
           press = function() { button.style['background-color'] = "red";                button.style['z-index'] = "1"; button.style['transform'] = "scale(2)";                          callback.call( recipient ); },
         release = function() { button.style['background-color'] = button.default_color; button.style['z-index'] = "0"; button.style['transform'] = "scale(1)"; if( release_event ) release_event.call( recipient ); };

That's not code that anyone is meant to have to check ever, it's just boilerplate for making some buttons, so my goal is to just get it out of the way and leave more room in the file for spreading out the more crucial parts for understanding the math that the library does.

Dumb Lowtax posted:

I hope I'm not like that.

Dumb Lowtax posted:

I hope I'm not like that. Some of my students complain that I use a very "horizontal" coding style. Indeed I take a lot of measures to save lines of code, and word wrap being OFF is *required* for reading it

quote:

If a line of code I wrote is that long it's usually because it's uninteresting, old, solidified, tested, and unnecessary for understanding the rest of the lines. And if there's multiple lines around it that share a lot of parts I'll be sure to vertically align those parts.

quote:

code:

  { let button = parent.appendChild( Object.assign( document.createElement( "button" ), { default_color: color, textContent: "("+shortcut_combination+") "+description, style: "background-color:" + color } ) ),
           press = function() { button.style['background-color'] = "red";                button.style['z-index'] = "1"; button.style['transform'] = "scale(2)";                          callback.call( recipient ); },
         release = function() { button.style['background-color'] = button.default_color; button.style['z-index'] = "0"; button.style['transform'] = "scale(1)"; if( release_event ) release_event.call( recipient ); };

CPColin posted:

You're like that.

TooMuchAbstraction posted:

Yeah, this is a lovely way to code. If you want to hide the "create a button" logic so it doesn't interfere with the code around it, then put it in its own function. There is absolutely nothing wrong with having a function that's only ever called once. You get to isolate the inputs/outputs/execution context of the code, you can shove the function to the bottom of the file or whatever, you can give it a nice name like createsBoringButton, and yet if I need to debug it I can still read what it's doing.

Dumb Lowtax posted:

Oh it is certainly in it's own function - the line above it is the function declaration, and it's actually a method in a small class (the whole class fits on less than a screen). It's very obvious to not read that code unless you care about how my buttons specifically animate themselves.

This horizontal style actually does not interfere with debugging at all, in a modern browser that is. For a while Chrome at least has been able to insert multiple breakpoints per line (you get to narrow down which statement on the line gets the breakpoint after clicking the breakpoint bar) and you can step execution through those multiple statements, so from a debugger standpoint it doesn't really throw off your flow to step horizontally versus vertically. You can still see what's going on to just as fine of detail.

CPColin posted:

You're also putting two spaces after sentences. On the Internet.

Dumb Lowtax posted:

Off the internet that's still pretty much universal and accepted as easier on the eyes, right? And even online it seems controversial:

https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Archive_(spaces_after_a_full_stop/period)

I like for structural things (like breaks between sentences) to stand out. I like small paragraphs too.

Dumb Lowtax posted:

That's not code that anyone is meant to have to check ever,

Dumb Lowtax posted:

I can never fit a whole library in my head at once and I don't like what they do to my confidence in whether I fully understand what my program is doing or not. I hate the uncertainty of using something with a lot of layers.

JawnV6 posted:

I dunno you seem hell bent on having it both ways. It's boring code that's well-tested and nobody should ever touch, yet at the same time it's utterly critical that it exist on-screen when you're looking at that function. Well, which is it then?

ynohtna posted:

What kind of students do you have, and do you recommend that they adopt your coding style?

Dumb Lowtax posted:

Its structure is on screen (on the left side) but its most boring details are off screen (past the right edge). That way I still see the class method exists, see its arguments and code comments and have a concept of how long it is, and know that the class has it available. I can just read down the list of methods on the left side of the screen and get the gist of the structure of the class without having to scroll a lot. If something goes off-screen to the right, that's "my version" of code folding - I know it's there and I can expand it by scrolling right if I need to dig in, but usually I just need concepts about structure in my head.

Dumb Lowtax posted:

It's actually a method in a small class (the whole class fits on less than a screen). It's very obvious to not read that code unless you care about how my buttons specifically animate themselves.

Dumb Lowtax posted:

code:

  { let button = parent.appendChild( Object.assign( document.createElement( "button" ), { default_color: color, textContent: "("+shortcut_combination+") "+description, style: "background-color:" + color } ) ),
           press = function() { button.style['background-color'] = "red";                button.style['z-index'] = "1"; button.style['transform'] = "scale(2)";                          callback.call( recipient ); },
         release = function() { button.style['background-color'] = button.default_color; button.style['z-index'] = "0"; button.style['transform'] = "scale(1)"; if( release_event ) release_event.call( recipient ); };

Plorkyeran posted:

They both have the same fundamental problem: they are deliberately written to not be readable by other people. Differences such as the quality of the variable names are trivial compared to the difference between code which is trying to be readable, and trying not to be.

Dumb Lowtax posted:

Painstakingly making every repetitive detail stand out by horizontally aligning it with spaces so the reader doesn't have to re-read similar things means pretty much the opposite thing as that about my intentions

Dumb Lowtax posted:

The library is a wrapper for low level WebGL calls so that computer graphics students can abstract out certain things and just focus on rotating, translating, and scaling 3D shapes. Usually their coding style is not like that, but then again, neither is mine when I'm actually designing a scene or prototyping something new as opposed to compressing wrapper code that I know pretty well.

Dumb Lowtax posted:

low level WebGL calls

Dumb Lowtax posted:

Painstakingly making every repetitive detail stand out by horizontally aligning it with spaces so the reader doesn't have to re-read similar things means pretty much the opposite thing as that about my intentions

Dumb Lowtax posted:

You don't have to have my exact screen size, you just have to mostly expect to see the most interesting and structural stuff towards the left side of the text, and not use word wrap.

Dumb Lowtax posted:

Off the internet that's still pretty much universal and accepted as easier on the eyes, right?

canis minor posted:

Alternative namings taken from synonyms - ringtail, procyon - and that's where English is not my primary language (I mean there are probably some weird native/regional words for racoon he could have used). I'd think that taking context into consideration is something that programmers should know about; instead he chose "blip, blop, i'm a robot, all words are equal"

Volte posted:

Two spaces after a period is a relic of the typewriter era and has never applied to text rendered in a proportional font, online or off. Browsers won't even render consecutive spaces after the first one.