While it's true that many composers use enharmonic equivalents for readability or to simplify transposition, there are cases where composers prioritize the functional role of chords and notes within the scale or harmonic context. In such instances, flats and sharps can coexist in the same score, and even double flats or double sharps may appear instead of their enharmonic equivalents. This approach ensures that the notation reflects the theoretical structure of the music, such as voice leading, chord functions, or adherence to a specific scale.

For example:

• In a C diminished 7th chord (C–Eb–Gb–A), the A is often written as Bbb in certain harmonic contexts to preserve its function as a 7th.
• Or in jazz, we have chords such as (C-D#-E-G-Bb), which is an altered chord that uses both sharps and flats. This is the Hendrix Chord.

So while readability is often a priority, there are musical contexts where strict adherence to theory takes precedence. It's fascinating how notation choices can vary depending on the composer's intent and the piece's complexity!

If I understand the concerns raised by users below, the main issues are:

• A single score usually does not contain flats and sharps (unless key changes etc.),
• A flat should usually transpose to a flat, and a sharp to a sharp.

The problem is that I am not familiar enough with the domain of music to know how much of a problem it is if the above "usually" are violated in a coding challenge :)

Separating sharps from flats in inputs, if done, should not be a problem because this does not affect solutions.
Forcing flats-to-flats and sharps-to-sharps would break solutions, but I would personally not worry much about this TBH. I think it adds an interesting twist, still in scope of the rank, and new solutions will appear quickly. I am not a fan of beding backwards too hard only to keep old solutions, if invalidating them would allow improvements in quality.

Suggestion: add combination of flats and sharps in input, and add additional input arg to expect output in either flats or sharps. Make that param optional for backward compatibility of existing solutions (if backward compatibility is even possible).

Yes I planned to add C# I was just trying to figure the extent to which I want to modify this kata to address domain issues reported below (I.e. sharps vs flats in inputs and outputs).

no issue

I would keep the issue open. It is not clear from description whether an "interval" goes up or down.

Transposing a single note means shifting its value by a certain interval.

EDIT: nevermind, the description states it:

This is using sharp notation, where '#' after a note means that it is one step higher than the note.

• Could use a C# translation, as the other kata got retired.
• Also, as the kata with better quality was retired, we should really improve quality on this one -> EDIT: open issues resolved

This kata was decided to stay.

Enabled in this fork

This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/224.
Please join the discussion to help us identify duplicate kata and retire them.

Perfect!

• your code is not readable sir with this format ,visit : https://docs.codewars.com/references/markdown#displaying-code
• to make sure that people can read it well

Beautiful, simple and efficient.

a nice tap!