top 50 comments

sorted by: hot top controversial new old
[–] 75 points 2 years ago* (2 children)

There is an other.

int * p;

  • source
  • hideshow 4 child comments
  • [–] 94 points 2 years ago (2 children)
  • [–] 68 points 2 years ago (2 children)

    Having an asterisk both be the type indicator and the dereference operator is one of the great programming language design blunders of our time, along with allowing nulls for any type in so many languages.

  • source
  • hideshow 4 child comments
  • [–] 20 points 2 years ago (3 children)

    I also sometimes wish that the syntax in if statements was inverted, where () was optional and {} was required.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 3 points 2 years ago* (last edited 2 years ago) (2 children)

    Can you give me an example? I'm not sure I follow. Might be language specific?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 6 points 2 years ago* (last edited 2 years ago) (1 child)

    The code in the image is C or C++ or similar. In those languages and languages derived from them, curly braces are optional but the parentheses are required. It should be the other way around to avoid logic errors like this:

    if (some expression)
      doSomething()
    else if (some other expression)
      printf(“some debugging code that’s only here temporarily”);
      doSomethingElse();
    

    Based on the indentation you’d think that doSomethingElse was only meant to run if the else if condition was true, but because of the lack of braces and the printf it actually happens regardless of either of the if conditions. This can sometimes lead to logic errors and it doesn’t hold up to a principle of durability under edit — that is, inserting some code into the if statement changes the outcome entirely because it changes the code path entirely, so the code is in a sense fragile to edits. If the curly braces were required instead of optional, this wouldn’t happen.

    I have all of my linters set up to flag a lack of curly braces in these languages as an error because of this. It’s a topic that sometimes causes some debate, ‘cause some people will vociferously defend their right to not have the braces there for one liners and more compact code, but I have found that in general having them be required consistently has led to fewer issues than having arguments about their absence, but to each their own. I know many big projects that have the opposite stance or have other guidelines, but I just make ‘em required on my own projects or projects that I’m in charge of and be done with it.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 6 points 2 years ago (1 child)

    Having assignments return a value is right up there as well.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 59 points 2 years ago (8 children)

    The fact it's a pointer is part of the type, not part of the variable name. So int* p is the way.

  • source
  • hideshow 14 child comments
  • [–] 86 points 2 years ago* (6 children)

    You would think so, but int* a, b is actually eqivalent to int* a; int b, so the asterisk actually does go with the name. Writing int* a, *b is inconsistent, so int *a, *b is the way to go.

  • source
  • parent
  • hideshow 12 child comments
  • [–] 38 points 2 years ago (1 child)

    When people say “pointers are hard”, they mean “I have no idea where the star goes and now an ampersand is also implicated”.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 16 points 2 years ago

    Then again, at least in C, the mantra is "declaration follows usage". Surely you don't write pointer dereferences as * ptr? Most likely not, you most likely write it as *ptr. The idea behind the int *ptr; syntax is basically that when you do *ptr, you get an int.

    And with this idea, stuff like function pointers (int (*f)(void)), arrays of pointers (int *a[10]) versus pointers of arrays (int (*a)[10]) etc. start making sense. It's certainly not the best way to design the syntax, and I'm as much a fan of the Pascal-styled "type follows the identifier" syntax (e.g. let x: number;) as anyone, but the C way does have a rhyme and a reason for the way it is.

  • source
  • parent
  • [–] 6 points 2 years ago* (last edited 2 years ago) (3 children)

    It's part of the type yet it's also a unique identifier. That's the whole thing with east or west const. const int * is a immutable mutable pointer that points to mutable immutable memory. int *const is a mutable immutable pointer that points to immutable memory. int const * is the same type as the first example, a immutable mutable pointer that points to mutable immutable memory.

    Same stuff applies to references which makes it easier to think of the variable owning the * or & as if you want that pointer or reference to be const it has to go after.

    Edit:I am a moron who managed to get it exactly backwards :|

  • source
  • parent
  • hideshow 5 child comments
  • [–] 7 points 2 years ago (2 children)

    Found the guy that can probably do function pointers!

  • source
  • parent
  • hideshow 4 child comments
  • load more comments (1 reply)
  • [–] 3 points 2 years ago

    tbh I always think about it as 'p' is a pointer to int

    therefore *p is an int

    therefore I should call it int *p;

    however, of course, you should use what your team prefers. Having good yet inconsistent style is worst than mid consistent style.

  • source
  • parent
  • load more comments (2 replies)
    [–] 17 points 2 years ago

    std::shared_ptr<int> p;

  • source
  • [–] 15 points 2 years ago (2 children)

    I'm just a c# dev wishing to fuck we had something visual to indicate reference types so my coworkers could stop misusing them

  • source
  • hideshow 3 child comments
  • [–] 14 points 2 years ago
    [–] 4 points 2 years ago

    no int * ptr fans here?

  • source
  • load more comments
    view more: next ›