Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One thing I’d add to this is that your database schema and your UI data model and/or API are decoupled so you can update your front end to the new representation before you do any database changes.

One thing I liked was the chosen example is changing Booleans to enums. This almost always happens. Your field is almost never a Boolean. This goes for code too. We’ve all read code like:

    foo(false, false, true, null);
This leads to coding standards that all such parameters must be commented and breakages when the parameter list is changed. It also often results in hacks to squeeze a third value into your Boolean (eg Optional<Boolean>).

Or, my favorite:

    @nullable Optional<Boolean>
As I like to say: for when three values for your Boolean just aren’t enough.

So yeah, my tip for the day is just make any Boolean an enumeration from the outset.



    enum Bool 
    { 
        True, 
        False, 
        FileNotFound 
    };


Don’t ever make True be the first item in an enumeration if there are any languages in your stack that initialize them by default. Make the default item be InvalidIForgotToInitializeThis.


One of my favourites features in Python are named parameters. I even wish Java could be more verbose in that manner.


You'd be surprised how many people are against this feature. I thought it'd be a no-brainer when it was proposed in the D community, but there was a lot of pushback against the feature (it's not implemented yet but it was accepted for the language). The main argument was that named arguments will cause your code to break when the arguments are renamed.


> The main argument was that named arguments will cause your code to break when the arguments are renamed.

Here's the counter point : ordered argument list will break if the order is re arranged in the defined function. While for named arguments it doesn't.


> Here's the counter point : ordered argument list will break if the order is re arranged in the defined function. While for named arguments it doesn't.

Counter-counterpoint: Once you add support for named arguments, your cannot do either, as you don't know which convention the caller uses.


in Python you can (and should) define your keyword arguments as keyword-only, for that very reason.


Seems acceptable since names are now part if your interface, and you could object that now you can relax ordering. Whats more interesting is that python has position only and name only arguments, meaning that there are uses for both.


I go back and forth on Python in this regard, specifically the named vs positional arguments in that an argument can be one or the other.

Part of me prefers just using an anonymous object in Javascript. Typescript is also cleaner than that.

Day to day I use Hack (FB's PHP fork), which has a type system and shapes, which are essentially anonymous objects in the JS/TS sense but a little more awkward syntactically:

    function foo(shape(
      'a' => int,
      'b' => int,
      ?'c' => int,
    )): void;

    foo(shape('a' => 1, 'b' => 2));
But with Python you sort of have this awkward mix of args and kwargs.


You can mark args as keyword only or positional only in the recent versions of Python (starting 3.7, maybe?)


If the project permits it, Kotlin fills that gap in Java well. Named parameters + defaults + nullability is a nice combination to have when it comes to evolving functions or types with backwards compatibility in mind.


This is good advice since some DBs (like MySQL) store booleans as 8 bit ints anyways.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: