User:Int 80h

From Wikipedia, the free encyclopedia
Int 80h
Entity
NickInt 80h
EducationUniversity
OccupationStudent, Teacher, Slacker
Motto"Ich denke, also spinn' ich"
(English: "I think, therefore I am nuts")
OH MY GOD HOW DID IT GET HERE I AM NOT GOOD WITH COMPUTER

User pages on Wikipedia are pretty useless in my opinion. I've got absolutely no idea what to put in here...

Oh, and it's not as if I'm the only user that suffers from lack of ideas. Pretty much every user page I've seen is boring and not even worth the storage space.

Font face of choice[edit]

I have my personal selection of fonts for every day use. For Wikipedia, I use Vollkorn right now, as you can see in my common.css I've been using Linux Libertine for quite a while, though. I suggest people don't succumb to using sans-serif (Antiqua) fonts for web pages.

People should experiment more with serif fonts on web pages. They look great and are just so pleasing to the eye.

Vi or Emacs?[edit]

Well, this question is more important to life, than things like "Why is my VT220 putting my cursor keys into application mode, when I attach my screen session?", or: "Why is my torrent still not finished downloading‽". So to pre-empt further questions:


Vim


Why Vim (or gVim, even)? Because that's the editor I feel the most comfortable with. Using hjkl as keys to move the cursor around, has nothing to do with it, from a geekness standpoint. I just like the syntax highlighting, the modal behavior, etc. Choosing hjkl as movement keys, has historical reasons, btw. Increasing efficiency because you don't have to move the hand from the home row, had nothing to do with it - trust me (and if you don't, read the article about the Lear Siegler ADM-3A terminal).

Indentation style[edit]

So, when it comes to indentation styles, there's actually a war going on, just like with everything else of social unimportance...

There are plenty of established indentation styles, but none of them seems to suit what I need in indentation, so here's mine.

It's basically Allman style, but with the opening brace on the statement line. I used (normal) Allman style, it works good with almost any of the C-like languages like Java:

class Whatever extends NoCares implements LameInterface
{
    public static void main(String a)
    {
        for(int i = 0; i < 10000; i++)
        {
            if(i == 3)
                i++; // O_o
            else if(i == 9000)
                System.out.print("IT'S OVER NINE THOUS");
            else if(i >= 9000)
                System.out.print("A");
        }
        System.out.println("ND!");
    }
}

I used the extra space after the opening brace for a one-line comment what this function (or method) does:

     private void doNothing()
     { // XXX this method does absolutely nothing. It's broken, too!
         Nothingness n = new Nothingness();
         //...
     }

What I like about Allman style, is that in if-then-else statements, each statement has no closing brace in front of it, which is absolutely idiotic in K&R or whatever indentation style, that does that. When the content of a block is just one line of code (like in the example above), I tend to leave out the braces, the indentation of if-then-else statements will not be broken!

So why even changing it, since it's oh, so perfect?

Well, there are languages like Perl, where you simply can't use one line statements without enclosing braces. In while or if-then-else statements, for example. The code becomes increasingly ugly:

if(/foo/)
{
     &bar;
}
elsif(/bar/)
{
     die "BAZ!\n";
}
else
{
     print "¯\\(O_o)/¯\n";
}

Well, actually, you can. But putting an if statment after the command that should be executed if the if is true, is somewhat obfuscating, even though it is a nice mingle of programming paradigms.

Anyway, since I don't like what my Perl code looks like in Allman style, I simply put the first brace of a block on the statement line:

if(/foo/) {
     &bar;
}
elsif(/bar/) {
     die "BAZ!\n";
}
else {
     print "¯\\(O_o)/¯\n";
}

No K&R ugliness, no stretching of white space, perfect. Not being able to put a comment in the first line of a method, function, or whatever an opening brace needs, is not that inconvenient, actually. Usually, the opening brace leaves enough room to put a comment after it (even when trying to stay within 80 characters).

Another difference is not using spaces between a control statement and the parameter parentheses, like for, while, and if:

for(int i = 0; i < 10; i++) {
    std::cout < i < std::endl;
}

while(true) {
    std::cout < "X_X ";
}

if(a) {
    func_a(a);
}
else {
    func_b();
}

Another oddity, I guess, is that I always use an extra line for a closing brace. in If-Then-Else statements, I don't use the "} else {" line, that's prominent in K&R, 1TBS, and BSD KNF. Instead, I put the closing brace of the previous block on its own line (see above example). I believe it makes those statements more akin to Switch-Case statements, and easier to comment out a control block.

Alas! There seems to be a name for what I use! Which is somewhat of a bummer, because I had a slim hope that it might've been named after me... right. So the Compact Control Readability Style, is a really cumbersome and long name for what I use. I still think it should be named after me.
No, it didn't. It seems that section was actually original research and has been removed. I'm OK with that!

I guess the thing I use can be best described by "Pythonic with braces and parentheses". Just do as you would in Python, and add braces after a block definition (opening brace), and on a single line closing that block (closing brace). This adds one extra line at the closing of a block, but if you didn't keep one single whitespace line after a block in python, you're a bad person anyway...
Parentheses go where in python would be just a space, so no extra space is used, and things look good and clear.

Interests outside the professional field[edit]

I do geocaching, but not crazily much of it, but it's a nice sport. I also like metal working.


In other news tonight[edit]

I speak more than one language, you can see them on my Babel chart. But don't be fooled, I can be insulting in many more languages.


How to nice quotation marks[edit]

As you can see in the section above, I speak langauages which take quotation marks rather damn serious!

Using them with an US-AltGr-Intl keyboard layout is of no bother! Check these key sequences and you improved your life tremendously:

  • AltGr+9 (this is often cited as the preferred symbol for an apostrophe, instead of ')
  • AltGr+0
  • AltGr+[«
  • AltGr+]»
  • AltGr+⇧ Shift+[
  • AltGr+⇧ Shift+]

Also note, that pressing AltGr+'+' (pressing ' twice while holding down AltGr) will produce ´, which is the reverse of `. Some typefaces might render these characters differntly, though, so hold on to your expremities!

Also note, there is no way (that I know of) to make the sub-level quotes and respectively, using AltGr.

So on to using Compose:

  • Compose,' (this is not a comma!)
  • Compose<'
  • Compose>'
  • Compose<<«
  • Compose>>»
  • Compose,"
  • Compose<"
  • COmpose>"

And just for completion ´ can be reached with Compose''.

Implicit ⇧ Shift isn't shown above.

Why you shouldn't use .txt as file extension for plain text[edit]

Short answer: because there is no plain text as such.

All text, no matter how plain still has an encoding. Mostly it's UTF-8 or ASCII these days - they're mostly compatible, but not stating it explicitly, makes it anyone's guess.

Most of the time, text files will be encoded in UTF-8 these days. hence, I propose the extension .utf8 in those, most cases. Should the file be explicitly ASCII, the extension should be .ascii, however as ASCII is a subset of UTF-8 mostly. .txt might be a file, encoded in some ANSI codepage that people forgot about. If it was in the extension, things would be much simpler. I've been using that extension for around ten years now, and almost all people immediately identify that file as being human readable plain text in UTF-8. I've come across people expecting a list of UTF-8 codepoints and their symbols, though.

The idea is mostly taken from Locale (computer software), where the modifiers work a bit like file extensions, for instance: en_US.UTF-8 .

Don't be temped to use the extension .t (as I was a long time ago). This extension is kinda reserved to the Turing programming language. I've never used it, and to me it'd seem it's super niche and rarely used, but it's its extension, so no plain text inside a .t