Если авторы предоставили ссылку на свой код в качестве ссылки, то уместно предложить комментарий, особенно если статья основана на коде.

Тем не менее, я бы порекомендовал сделать критику конструктивной: предлагать конкретные предложения по улучшению, а не просто говорить, что это «грязно» или «неряшливо» и требует «очистки».

Код находится в рамках обзора, и уместно рассмотреть его и предложить конструктивные предложения в отношении его недостатков. Теперь имейте в виду, что на авторе лежит обязанность удовлетворить рецензентов своей аргументацией, и если аргумент зависит от компьютерного кода, который настолько запутан, что его невозможно прочитать, вы не обязаны исправлять это за них. В этом случае конструктивный совет может быть ограничен объяснением того, почему его в настоящее время слишком сложно читать (т. е. отсутствие отступов, неясные имена переменных и т. д.), и это может разумно привести к рекомендации пересмотреть и отправить повторно. Постарайтесь быть ясным и исчерпывающим в описании того, почему код в настоящее время трудно читать, поэтому можно ожидать, что последующие повторные отправки будут на должном уровне.

В таких случаях лучше всего обращаться с компьютерным кодом так же, как с прозой в газете. Как и в случае с прозой, компьютерный код должен быть ясным и понятным в соответствии со стандартами кодирования. Если он беспорядочный и непонятный, его необходимо пересмотреть, пока он не станет ясным. Рецензенты не уклоняются от отклонения статей, если проза непонятна, поэтому вполне разумно требовать сделать компьютерный код понятным.

Да, вы должны прокомментировать и, возможно, больше.

Вы сами сказали:

Многие результаты в статье сильно зависят от компьютерных вычислений.

Что ж, программный код для вычислений, таким образом, является частью работы, которую вы просматриваете. Если бы текст статьи было трудно читать, вы бы не сочли это слабостью? Таким образом, логически то же самое верно и для кода (хотя и в несколько меньшей степени).

Кроме того, если код для вас нечитабелен - возможно, в нем есть ошибки, несмотря на здравую математику внизу. И, наконец, если вы можете сказать, какими должны быть результаты без кода, то зачем вообще нужен код?

Так что, если вы чувствуете, что беспорядок не препятствует «разбору» документа, то прокомментируйте его (и, возможно, если это уместно, понизьте его с «Сильное согласие» на «Слабое согласие», хотя, возможно, это слишком резко — зависит от специфики.)

Если вам нужно прочитать код, чтобы получить очень хорошие результаты, а вы просто не можете, то это более серьезная проблема. Но прежде чем говорить что-то вроде «Требуется доработка», проконсультируйтесь с редактором журнала/председателем программного комитета/и т.д.

_{Примечание. Я компьютерный ученый, поэтому мой ответ может быть несколько предвзятым. С другой стороны, я написал чисто теоретическую работу без кода.}

Грязный код влияет на воспроизводимость

Вы пытались воспроизвести их результаты с помощью связанного кода и не смогли этого сделать. Хотя вы подразумеваете, что в конечном итоге смогли разработать свой собственный код и воспроизвести результаты, я утверждаю, что плохо написанный код влияет на воспроизводимость. В компьютерном программировании это может быть даже более важным, поскольку языки программирования не обязательно имеют очень долгую жизнь. Кто знает, станет ли Magma или любой другой язык общеизвестным через 50 лет.

В долгосрочной перспективе воспроизводимость является наиболее важной частью научных усилий. Доказательство того, что aдействия приводят к b, факт, который может быть повторно доказан любым, кто хочет попробовать, является аксиоматически строительным блоком, на котором могут основываться дальнейшие научные результаты.

Если важна воспроизводимость, то нет ничего плохого в том, чтобы попросить их очистить свой код. Откровенно говоря, если их код так плох, как вы описываете, похоже, что авторам будет трудно понять свою собственную работу, возвращаясь к ней через несколько лет. В этом случае, заставив их немного научиться писать хороший код, вы сделаете им одолжение.

Позвольте мне кратко коснуться аспекта, который не фигурировал в существующих ответах.

Мой вопрос: разумно ли мне говорить авторам, что их код излишне сложен для понимания и его следует улучшить?

Да , вы должны комментировать код, но не только это: убедите авторов, что в их интересах исправить эти проблемы.

Читаемый код — это код, который легко использовать повторно. Повторно используемый код — это код, который упрощает изучение математики, представленной в статье. Исследовательская математика, скорее всего, найдет читателей, которые найдут интересные расширения. Публикуются интересные расширения, и в этих публикациях цитируется исходный код — и, кроме того, приводятся одни из самых ценных ссылок.

Создание читабельного и повторно используемого кода не гарантирует, что это произойдет, но если вы публикуете нечитаемый код, вы создаете искусственный барьер перед читателем, который может или не может продолжить дальнейшее исследование на основе вашей работы, и если таких барьеров достаточно, этот читатель просто обратится в другое место. Сделать код читабельным — это скромное вложение времени, которое приводит к значительному улучшению расширяемости работы.

Это возведение барьеров, конечно, не уникально для кода: нечеткие цифры, запутанная структура, запутанная грамматика, отсутствующие леммы и множество других проблем могут создавать подобные барьеры, и ваша работа в качестве рецензента включает в себя указывая на них и помогая авторам избавиться от них. Код ничем не отличается — помогите им улучшить его!

Я не работаю в академических кругах и не рецензирую статьи/документы на этом уровне (дополнительно в технической школе), но я оцениваю много домашних заданий по программированию и нечетные образцы технических документов, и я занимаюсь разработкой программного обеспечения, чтобы фактически оплачивать счета.

Если статья зависела от вывода сгенерированного кода, то код должен быть читабельным и понятным - в противном случае код может не делать то, что думает автор, и другие не смогут подтвердить это без их собственной повторной реализации. Если такая повторная реализация относительно тривиальна, то кажется, что фактический код не важен, и поэтому я задаюсь вопросом, почему сломанный код для чего-то, что легко реализовать на основе спецификации, будет включен или упомянут в научной статье.

Учитывая, что вы смогли проверить, используя свой собственный код, реализацию его алгоритма (ов), я не думаю, что это так, но это следует принять во внимание. Любая приличная IDE или даже продвинутый текстовый редактор должны уметь автоматически форматировать код и выполнять поиск/замену по всему проекту (рефакторинг). Типа намекает на банальную лень....

Авторы предоставляют ссылку в статье , поэтому код считается либо ссылкой, либо частью исследования. В любом случае это вызывает вопросы:

1. Код заархивирован? Практические способы архивирования кода включают Zenodo или figshare . Код на домашней странице так же хорош, как и его отсутствие.
2. Есть ли лицензия на код? Если нет, то его статус вообще не очевиден.

Вам, как рецензенту, решать, что делать. Возможные действия включают в себя:

1. Не комментируйте код.
2. Прокомментируйте код с тем, что я бы назвал минимумом: требуйте, чтобы код был заархивирован и лицензирован должным образом.
3. В зависимости от важности компьютерной программы в исследовании требуется минимальная удобочитаемость и чтобы автор предоставил некоторые тесты программы (т. е. чтобы программа давала известные аналитические ответы, если это позволяют некоторые наборы параметров, и т. д.).

Что касается архива, вы можете обратиться к редакционной информации журнала Open Research Software .

Я инженер-программист и хочу ответить на вопрос с этой точки зрения. Большая часть кода не читается сама по себе. Вы должны иметь комментарий для документирования структур данных и спецификаций для вызовов подпрограмм. Академики не являются инженерами-программистами, и я не ожидаю от них профессиональной работы в этом отношении. Тем не менее, это, безусловно, для того, чтобы прокомментировать качество программного обеспечения. Не глядя на реальный код, я не уверен, что стал бы комментировать, что он нечитаем, потому что статья (то есть, согласно показаниям, достаточным для воспроизведения кода) должна считаться частью документации программы. Если в программе используются короткие имена, такие же, как в статье, это не проблема. Отсутствие отступа — это не показатель низкого качества, а многоуровневостьотступа. Я бы предложил вам выразить свое ощущение, что вам трудно читать, но вы также не являетесь экспертом по коду, и, возможно, пусть какой-нибудь инженер-программист просмотрит его. Знаете, это другой набор навыков. Это должно снять остроту комментария.

В довершение всего: я проделал хорошую работу по очистке кода, который я не понимал на уровне цели. Вы будете удивлены, на что способен эксперт в другой области.

Суть в том, что код не важен, качество кода второстепенно и никак не должно влиять на ваше решение.

Насколько я понимаю, авторы не отправляют код для публикации, поэтому код, похоже, не подлежит вашему рассмотрению. Авторы просто дают ссылку на свой код. Возникает вопрос: если бы они просто дали ссылку на свою работу, опубликованную в другом месте, стали бы вы говорить им, что этаработа должна быть улучшена? Можно возразить, что достоверность их результатов зависит от правильности их кода, но они могут вообще не предоставлять доступ к коду, поскольку «математика, лежащая в основе этих вычислений, объяснена достаточно хорошо, чтобы можно было воспроизвести результаты без с использованием авторского кода». Вы, как рецензент, взяли на себя труд проверить результаты их вычислений, тем самым выходя за рамки своих обязанностей, но это означает, что их результаты действительно воспроизводимы.

Поэтому я думаю, что вы можете упомянуть, что их код паршивый (хотя, по-видимому, правильный), но это не должно повлиять на вашу рекомендацию по публикации/не публикации статьи.

Я не знаю ни одного научного журнала, который основывал бы свои решения на коде. Будь то грязный или нет, это не касается журнала. То, что это должно быть воспроизводимо, должно вызывать озабоченность, но я не знаю ни одного журнала, который сделал бы это критерием, за исключением некоторых инициатив для некоторых сообществ, например, NIPS, CVPR. На мой взгляд, это уже бонус, что они решили его выпустить (а в некоторых случаях людям даже не разрешено выпускать их из-за правил их организации). Если у вас есть какие-либо утверждения о том, что код неверен или не делает то, что он должен делать, это может быть другая история, но вам нужно обосновать это. Если вы хотите сделать замечание только по поводу неряшливости кода, я думаю, вы должны уточнить свой комментарий и подчеркнуть, что это не влияет на общий обзор, я согласен с комментарием, сделанным ранее»