Is there a convention on how to write pseudocode in scientific papers?

As you are already stating: There is no norm / convention for pseudocode.

Personally, I prefer a python-like notation, but this is because I like python ;-). CLRS is fine for many purposes.

If your software is written in a specific language, it might be beneficial to use a code convention which allows you to express the specifics of your programming language - this reduces the risk of introducing errors.

Even more important then the code convention is, that you should ensure your pseudocode allows someone else to re-implement your code without room for interpretations. Sometimes, "real" code can be more appropriate (but yes, it can be lengthy).

A de-facto sort-of-convention is using one of the LaTeX algorithm listing packages, e.g. algorithm2e, algorithms or algorithmicx.

Each of the packages have a documentation PDF which includes several examples you can follow, and have multiple in-built commands for things like conditions, repetition, clauses, etc. Alternatively, you can have a look at the Algorithms section of the LaTeX WikiBook, which is shorter and simpler and mentions all three. Pick one and use it.

Here's a brief example:

\usepackage[]{algorithm2e}
% ... etc. etc. ...

\begin{document}

% ... etc. etc. ...

\begin{algorithm}[H]
 \KwData{this text}
 \KwResult{how to write algorithm with \LaTeX2e }
 initialization\;
 \While{not at end of this document}{
  read current\;
  \eIf{understand}{
   go to next section\;
   current section becomes this one\;
   }{
   go back to the beginning of current section\;
  }
 }
 \caption{How to write algorithms}
\end{algorithm}
% ... etc. etc. ...
\end{document}

and this produces:

Now, even if you don't write your documentd with LaTeX, you could write just your pseudocode that way and use the resulting PDF, or just copy the resulting text into whatever editor you are using.

Edsger Dijkstra used a notation in most of his papers that was also adopted by David Gries in The Science of Programming. If you are happy enough with a procedural approach and don't require functional or object-oriented notations then it is a pretty good choice with a long history.