Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. The Lounge
  4. Coding style
QtWS25 Last Chance

Coding style

Scheduled Pinned Locked Moved The Lounge
4 Posts 4 Posters 2.8k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    florent.revelut
    wrote on last edited by
    #1

    EDIT: Coding style discussion from thread "file size":http://developer.qt.nokia.com/forums/viewthread/4772/ has been moved to this separate thread

    Original comment that is referred to:

    [quote author="vinb" date="1301333819"]try this:
    @
    QFile mio_f(nome);
    if (!mio_f.open(QIODevice::ReadOnly))
    return; //when file doesnt open.
    size = mio_f.size(); //when file does open.

    @
    where 'nome' is a var with the path to file in it || nome is path to file

    [/quote]

    Regards, Volker

    well, I disagree a but with vinb, it's commonly seen as bad practice to have more than one exit point per function. Moreover, leaving the indentation like that is misleading : size doesn't look on same level as if.

    For a junior developper, keeping good coding rules is a must as it prevents easy mistake : my advice, use always brackets, even for single-lined blocks, keep one return point / one exit point per function (eases memory management)

    1 Reply Last reply
    0
    • Z Offline
      Z Offline
      ZapB
      wrote on last edited by
      #2

      [quote author="florent.revelut" date="1301335667"]well, I disagree a but with vinb, it's commonly seen as bad practice to have more than one exit point per function. Moreover, leaving the indentation like that is misleading : size doesn't look on same level as if.

      For a junior developper, keeping good coding rules is a must as it prevents easy mistake : my advice, use always brackets, even for single-lined blocks, keep one return point / one exit point per function (eases memory management)[/quote]

      In general yes, but this type of rule can be relaxed to some extent when using RAII classes such as QSharedPointer or QMutexLocker etc. or only using variables on the stack. Using RAII classes often makes for more readable functions as their destructors do the messy cleanup for you.

      Nokia Certified Qt Specialist
      Interested in hearing about Qt related work

      1 Reply Last reply
      0
      • A Offline
        A Offline
        andre
        wrote on last edited by
        #3

        [quote author="florent.revelut" date="1301335667"]well, I disagree a but with vinb, it's commonly seen as bad practice to have more than one exit point per function. Moreover, leaving the indentation like that is misleading : size doesn't look on same level as if.

        For a junior developper, keeping good coding rules is a must as it prevents easy mistake : my advice, use always brackets, even for single-lined blocks, keep one return point / one exit point per function (eases memory management)[/quote]

        You do realize that this is opposite to Qt's own coding conventions?

        I don't agree with the guidelines you give here. A single-line block does not need brackets, and there is no reason to keep a single exit point to a function as long as you don't rely on creating objects on the heap and destroying them again in the same function. Now that is something to avoid when possible, if you ask me.

        1 Reply Last reply
        0
        • G Offline
          G Offline
          goetz
          wrote on last edited by
          #4

          Adhering to the "single point of exit" dogma leads to unreadable code if you have more than two or three nested if statements and it puts else blocks far away from the corresponding if. I regard this as bad coding style and urge all my fellow programmers I'm responsible for to not use this pattern.

          Also, coding style is clearly a matter of taste - it's not helpful to bring in such topics into an obviously technical discussion. Please discuss these things in a new thread. Thanks.

          http://www.catb.org/~esr/faqs/smart-questions.html

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved