Find the proper names for next(), next1(), prev(), prev1(), etc. methods in segment.h

• Jun 2, 2018 - 17:03
Reported version
3.0
Type
Functional
Severity
S4 - Minor
Status
active
Project
MuseScore
Tags
3.0alpha
codestyle

The libmscore/segment.h has methods with not the best names. The same is in 2.3, but since 2.3 is the final 2.X version, let's find the better names in master only and keep legacy in 2.3.

      Segment* next() const               { return _next;   }
      Segment* next(SegmentType) const;
      Segment* nextEnabled() const;
      void setNext(Segment* e)            { _next = e;      }

      Segment* prev() const               { return _prev;   }
      Segment* prev(SegmentType) const;
      Segment* prevEnabled() const;
      void setPrev(Segment* e)            { _prev = e;      }

      // dont stop at measure boundary:
      Segment* next1() const;
      Segment* next1enabled() const;
      Segment* next1MM() const;
      Segment* next1(SegmentType) const;
      Segment* next1MM(SegmentType) const;

      Segment* prev1() const;
      Segment* prev1MM() const;
      Segment* prev1(SegmentType) const;
      Segment* prev1MM(SegmentType) const;

      Segment* nextCR(int track = -1, bool sameStaff = false) const;

      ChordRest* nextChordRest(int track, bool backwards = false) const;

Comments

• Jun 2, 2018 - 17:03
Title Find the proper names to next(), next1(), prev(), prev1(), etc. methods in segment.h ⇒ Find the proper names for next(), next1(), prev(), prev1(), etc. methods in segment.h

Reply

• Jun 5, 2018 - 16:31

My initial thought would be

  • next/prev: no boundaries, just does what it says and gives you the next/prev segment
  • nextInMeasure/prevInMeasure: the current next1 methods

I slightly cringe at having both nextCR and nextChordRest, and the former then not returning a ChordRest. The latter having a backwards parameter is not as clear as making a prevChordRest with the same signature.
Alternatively wondering if it wouldn't make sense to then integrate that into the "normal" next(SegmentType) call as next(SegmentType, track=-1, sameStaff=false)

But I can imagine making next/prev in my proposal work as the current next1 calls does will add to confusion and might make it easy to miss a call during refactoring.
In that case you could go for the more verbose:
* nextInScore/prevInScore
* nextInMeasure/prevInMeasure

Reply