There should be a "programmers license"...

Zecc

I've seen code formatted like this a while ago:

if(...)

    {

    while(...)

        {

        ....

        if(...)

            {

            Obj o = new Obj

                (

                arg1,

                arg2,

                arg3

                );

            ..

            ..

            }

        }

    }

I have no idea what to call this style (other than "annoying" and "misleading").
I have some ideas what to call its author though...

antiquarian

@Zecc said:

I have no idea what to call this style (other than "annoying" and "misleading").

Both of those work for me.

HardwareGeek

@Zecc said:

I have no idea what to call this style (other than "annoying" and "misleading").

Apparently this style is called whitesmith, and it is by no means the worst available "standard" style. Do not look at the subsequent styles on that page if you want to keep your sanity (assuming you have any).

Zecc

It looks like I mostly use the "One True Brace Style". Who woulda thunk it?

aliceif

I use Java style. And I don't even feel bad for it.

DrakeSmith

The lisp style hurts my brain... But doesn't lisp always do that?

boomzilla

Doesn't seem like there's an option to mangle the parameters to a method / function call and the parentheses, though.

Mo6eB

So this entire thing just sorts an array into an ArrayList using insertion sort? A static array of exactly two items, even.

This is my signature. There are many like it, but this one's mine.

Filed under: meh, seen worse

Onyx

Does it still count as Allman if I tend to wrap single-line blocks in brackets as well?

Also, what's the general opinion on something like:

if(condition)    return 1;
else             return 0;

I tend to do it sometimes when both the conditions and subsequent commands are really short.

Filed under: Yes, I intentionally wrote the example in a way that will piss off as many people as possible

DrakeSmith

I do that often as well - if I move the statement to a separate line, I always use braces, even if it is still a single statement on one line.

riking

IntelliJ says:

If condition can be simplified

return condition ? 1 : 0;

chubertdev

if (condition.ToString().ToLower().Substring(0, 1) == "t")
{
   return 1;
}
elseif (condition.ToString().ToLower().Substring(0, 1) == "f")
{
   return 0;
}

Onyx

I'd recommend you for "the most convoluted boolean ever" award. But as soon as I do that someone is gonna do something even more ridiculous.

chubertdev

switch (condition.ToString().ToLower().Substring(0, 1))
{
   case "w":
      return FILE_NOT_FOUND;
   case "t":
      return 1;
   case "f":
      return 0;
   default:
      throw new ArgumentException("condition is conditionally conditional");
}

Onyx

Wait. WTF is w from?

Oh,

Never mind.

DrakeSmith

@chubertdev said:

```cs
if ((condition.ToString().ToLower().Substring(0, 1) == "t") == true)
{
return 1;
}
elseif ((condition.ToString().ToLower().Substring(0, 1) == "t") == false)
{
return 0;
}
There, now it looks like what I'm used to.

chubertdev

@DrakeSmith said:

There, now it looks like what I'm used to.

I hate that pattern.

chubertdev

@Onyx said:

Wait. WTF is w from?

Oh,

Never mind.

It's like one of those "when you see it" things.

DrakeSmith

You're preaching to the choir. The code base I have deals with a lot of nullable booleans, and I cringe at the workarounds for it...

if (nullableBool == true)

versus

if (nullableBool.HasValue && nullable.Value)

They both look hideous. But of course I still see this:

if (nullableBool.HasValue && nullable.Value == true)

or even better

if (nullable.Value)  //Crash! Bang! Boom!

dkf

@PJH said:

I thought it was done through indentation...

Or this:
[...elided because DC quoting sucks…]

That's an awesome idea. I think I'll save the whole thing for use when I am editing my cow-orkers Python code. They'll appreciate it. (They'll also appreciate the mixing of different whitespace types.)

dkf

One way to one-up the ridiculousness is to compute the hash code of the boolean and test whether it is equal to the one you worked out earlier (and which you can obtain with whatever evil you choose). With a bit of luck, you'll create something that is both enterprisey and an utter horror to anyone following on as maintainer.

if (condition.GetHashCode() == UltimateTruth.FileNotFound) {
    // ....
}

Onyx

@dkf said:

(and which you can obtain with whatever evil you choose)

Is there even a choice? Bring out the XML!

Filed under: And all tags are hashes, I think I just invented the hashtag

Nagesh

XML is old. Now JSON is the bleeding age of things. Even JSON will get old in a few posts from now.

Onyx

JSON is (mostly) sane. We can't have that!

aliceif

JSON - It's the thing JavaScript was actually made for!

Onyx

@aliceif said:

JSON - It's the thing JavaScript was actually made for!

And, ironically, I usually find that, out of all the different systems using different languages, it's the biggest pain to work with... in JavaScript.

dkf

@Onyx said:

JSON is (mostly) sane. We can't have that!

OK. JSON-LD. JSON-Schema.

Arantor

No, not even close.

PHP's json_encode implementation is broken because it explicitly follows locale settings when outputting numbers. Which is fantastic in parts of Europe, of course.

presidentsdaughter

Please don't! Hashcodes. I'll write about them later...

cartman82

JSON is such a simple idea, you can sketch the entire spec on a napkin. And yet, they managed to screw it up.

Quotes around field names. So annoying.
No comments? Come on!
No objects? Not even built-ins, like Date or RegExp? Now you're just messing with people.

IMO JSON is another ad-hoc half-baked idea, that was intended for some obscure niche use (quick & dirty message protocols, if I recall), but somehow ended up being the pivot around which WEB 2.5 revolves.

dkf

@cartman82 said:

No objects? Not even built-ins, like Date or RegExp? Now you're just messing with people.

They've got plenty of objects. Just not the objects you wanted. (They call their named field mappings “objects”.) You're going to have to invent your own mapping layer to add typing back in if you need it.

Filed under: JSON: XML's pants-on-head retarded little brother

cartman82

I currently use a scheme similar to this:

{
   "date": "|d|2014-07-05 11-42-51|",
   "error": "|e|{'message': '...', 'stack': '...'}|"
}

Start with pipe to plug it into my resolver, then a single letter for the hardcoded type. If we find a match, the string representation between pipes is fed to the appropriate constructor. What if I want more types, custom types, less name collisions or not to have to hard code constructors into my JSON de-serializer? Ummm.... Use XML?

dkf

It's shit like that which is why I still have XML as my webapp's principal I/O format. Though I might instead go for:

{
   "date": {
      "@type": "date",
      "value": "2014-07-05 11-42-51"
   },
   "error": {
      "@type": "error",
      "message": "...",
      "stack": "..."
   }
}

It's layering a convention over the top of JSON, but that's quite possible.

You could also try using Badgerfish. It's really about making DOM pass through JSON, but that might be good enough for you as you could ignore most of the weirder bits in JSON-preferring client software.

cartman82

@dkf said:

It's shit like that which is why I still have XML as my webapp's principal I/O format. Though I might instead go for:

{
"date": {
"@type": "date",
"value": "2014-07-05 11-42-51"
},
"error": {
"@type": "error",
"message": "...",
"stack": "..."
}
}

Problem is, then I must know that "date" property should resolve into a date object, as opposed as being just another hash. Meaning, I have to keep some kind of schema which hashes are just hashes and which are representations of "constructed" objects.

dkf

@cartman82 said:

Problem is, then I must know that "date" property should resolve into a date object, as opposed as being just another hash. Meaning, I have to keep some kind of schema which hashes are just hashes and which are representations of "constructed" objects.

Yes, but it's better than using structured strings. It's the same information, but with the structure made explicit. Explicit is (almost) always better than implicit in data representation and serialization. (Yes, there's such as thing as JSON Schema.)

I'm sure we could find a WTF with someone putting fixed-length records into XML. That would be quite similar in concept to the mess you're thinking about doing.

cartman82

@dkf said:

Yes, but it's better than using structured strings. It's the same information, but with the structure made explicit. Explicit is (almost) always better than implicit in data representation and serialization. (Yes, there's such as thing as JSON Schema.)

I'm sure we could find a WTF with someone putting fixed-length records into XML. That would be quite similar in concept to the mess you're thinking about doing.

Already doing.

Works fine, actually. Since I have javascript on all levels, simple JSON is a pretty good fit. POJO goes in on one end, POJO pops out on the other. Most of my data are hashes anyway, so "magic strings" can easily handle the few cases where I need a meaningful class.

It would be different if I was connecting two strongly typed environments. In that case, I could use classes as "schemas" and wouldn't have to track a bunch of additional metadata (that's how JSON.NET works).

Captain

JSON is a great idea. It takes JavaScript's notation for objects, simplifies it a bit (no methods, just pure data fields), and turns it into a data transport language. But that's what it's for -- transport.

I do agree that it should have better types. But it's JavaScript's fault for not having better types in the first place. And also, I just have a hard on for better types.

But, and this is why it's so big for the Web, it is valid JavaScript. All you need to do is verify that it is properly formatted and slurp up the data into your front-end. There's no need for a parser library, because your browser already parsed it. It's like running eval on data from the server, except you can't feed in arbitrary code, just arbitrary data.

Using JSON in my workflow has reduced the amount of work I have to do by at least 50%. I use Knockout.js at the front-end, feed JSON in with the Knockout mapping plugin, and feed that in by serving up JSON data (duh). But the JSON data I feed in is effectively automatically derivable:

data ArticleView = ArticleView { author :: Text
                               , title :: Text
                               , contents :: Text
                               }
deriveJSON defAeson ''ArticleView

getArticleR :: Handler TypedContent
getArticleR = do
  -- authorization, etc goes here
  article <- getArticle -- query for the article to serve
  selectRep $ do
    provideRep $ returnJson article
    provideRep $ defaultLayout $ article_widget -- the knockout widget

article_widget :: Widget
article_widget = [whamlet|
  <div data-bind="text: title">
  <div data-bind="text: author">
  <div data-bind="text: contents">
|]

That, plus styling and a query, is what it takes to make an "article page". Throw some jquery and pager.js in there, and you have the makings of a full-featured ajax app.

error

@cartman82 said:

Quotes around field names. So annoying.
No comments? Come on!
No objects? Not even built-ins, like Date or RegExp? Now you're just messing with people.

If you read his book, he explains these choices [spoiler](though I disagree with many of his authoritarian stances, I can at least understand them)[/spoiler].

Quotes around field names? Javascript has problems with property names which are reserved words in the language, and he deemed putting those reserved words into the spec would be "ugly."

Comments? He wanted to prevent people embedding metadata into the comments, which would lead to many incompatible variants. And that's probably exactly what you wanted them for, right?

No dates? Well, fuck. I usually use Unix-style seconds-since-epoch here, or ISO formatted strings.

@cartman82 said:

Problem is, then I must know that "date" property should resolve into a date object, as opposed as being just another hash. Meaning, I have to keep some kind of schema which hashes are just hashes and which are representations of "constructed" objects.

I'm pretty sure @type is being used in his example for this porpoise [spoiler](Eee! Eee!)[/spoiler].

cartman82

@error said:

If you read his book, he explains these choices (though I disagree with many of his authoritarian stances, I can at least understand them).

Quotes around field names? Javascript has problems with property names which are reserved words in the language, and he deemed putting those reserved words into the spec would be "ugly."

*Used to have problems with property names. They should update the spec accordingly.

@error said:

Comments? He wanted to prevent people embedding metadata into the comments, which would lead to many incompatible variants. And that's probably exactly what you wanted them for, right?

No, I wanted to put docs inside my hand-crafted JSON config files.

@error said:

No dates? Well, fuck. I usually use Unix-style seconds-since-epoch here, or ISO formatted strings.

Don't like epoch, makes it unreadable. ISO date is OK.

dkf

@cartman82 said:

No, I wanted to put docs inside my hand-crafted JSON config files.

That's easy. Use the @documentation key (or any other if you prefer).

JSON doesn't have silent metadata. If you want to put metadata in, you can, but it has to be present in the resulting object tree. Don't like this? Use something other than JSON…

Zecc

@cartman82 said:

No, I wanted to put docs inside my hand-crafted JSON config files.

@cartman82 said:

Don't like epoch, makes it unreadable. ISO date is OK.

+1 x 2

Hey, multiquoting has been fixed. Yay!

@dkf said:

That's easy. Use the @documentation key (or any other if you prefer).

Because you only need to document one thing in each level. Or don't mind having a bunch of extraneous keys polluting your data model.

cartman82

@dkf said:

JSON doesn't have silent metadata. If you want to put metadata in, you can, but it has to be present in the resulting object tree. Don't like this? Use something other than JSON…

JSON way or the highway?

dkf

@cartman82 said:

JSON way or the highway?

Yes. (I don't like JSON very much. It pretends to be much lighter weight than XML, but isn't really once the data complexity reaches useful levels.)

Nagesh

@dkf said:

Filed under: JSON: XML's pants-on-head retarded little brother

http://imgur.com/gw7IEjM

Captain

"pico" is the only sane one in there. "lisp" is close, but the attached brackets are pretty dumb.

dhromed

@Onyx said:

Also, what's the general opinion on something like:

I demand a space after that keyword.

dhromed

@Captain said:

Throw some jquery and pager.js in there, and you have the makings of a full-featured ajax app.

That sounds so much to me like "draw the rest of the fucking owl".

Captain

I'm not trivializing the work at those layers, but jQuery, at least, is a common component and is fairly well understood in terms of budgeting. How hard it is to draw the rest of the owl depends on what you want it to do. It is also beyond the scope of my example.

Pager.js is truly trivial to use though. You just wrap divs in

<div data-bind="page: {id: 'name'}">

and you can link to that div with #name. It's for constructing single page apps.

Zecc

@dhromed said:

I demand a space after that keyword.

I've been writing like this in personal code:

if( !user.isBrillant() && !user.equals(president.getDaughter()) ){
    Dragon.burn( user, Dragon.BURN_LEVEL_CRISPY );
} else {
    return FILE_NOT_FOUND;
}

I like how it emphasizes the condition inside ifs and the operands inside the calls.
(For branches longer than one line I move the else to a new line.)

dhromed

@Zecc said:

I like how it emphasizes the condition inside ifs and the operands inside the calls.

I only do inner spaces when there's too many parens in the condition.

And don't you fucking dare to cuddle that else. You're not helping anyone.