A melhor maneira, de longe, é incluir todo o seu código como material suplementar. Se possível, inclua também arquivos com as sementes aleatórias relevantes necessárias para recriar seus resultados. Isso não apenas permite que as pessoas recriem seus resultados (com os quais você talvez não se importe), mas também permite que elas continuem mais facilmente de onde você parou. Isso permite novas colaborações e citações para o seu trabalho. Infelizmente, isso ocorre com a dificuldade de forçá-lo a limpar seu código e garantir que não haja erros. Portanto, é mais um ideal do que o habitual na prática. Mas, no mínimo, você deve arquivar uma versão do seu código usada para produzir seus resultados, assim, se outro pesquisador solicitar código, você poderá produzi-lo.
Em termos de descrição em seu artigo, eu me concentraria em uma descrição independente de implementação de alto nível dos principais recursos novos do modelo (esta é a parte prática que o melhor artigo consegue). Concentre-se nos recursos que alterarão qualitativamente o resultado se eles forem aprimorados. Muitos modelos com os quais trabalho produzem resultados quantitativos, mas as quantidades específicas geralmente não são de interesse, apenas o comportamento qualitativo (uma vez que os parâmetros geralmente estão longe dos observáveis na natureza). Assim, concentro-me em descrever as partes do modelo que, se alteradas, mudarão o comportamento qualitativo do sistema. Se essa mentalidade me forçar a descrever todos os detalhes do meu modelo até a implementação, então eu sei que meu modelo não é muito robusto e, portanto, deve ser descartado.
Uma boa maneira de testar se sua descrição em papel é suficiente é pedir a um amigo (ou aluno) que não trabalhou nesse projeto com você para descrever como eles podem implementar seu modelo com pseudo-código. Se eles não ficarem presos ao tentar fazer isso (como eles chegam a um esboço de um modelo que deve produzir os mesmos resultados qualitativos), então você sabe que fez um bom trabalho de descrição.