Проверяется идентификатор, с которым связана строка. Диагностика разбирает его на отдельные слова и ищет среди них различные ключевые фрагменты типа password и т.п.
Как я и говорил, чудес тут нет. Если Вам кажется, что алгоритм можно было бы как-то улучшить, то прошу поделиться этими идеями и возможно, они помогут нам сделать диагностику лучше :)
Как бы нам ни хотелось творить магию, чудес эта диагностика не делает :) V5601 рассматривает идентификатор, который связан с потенциально захардкоженными данными. Это может быть:
переменная/поле/свойство/параметр, куда записывается строковый литерал
параметр, в который передаётся строковый литерал
что-то, что сравнивается со строковым литералом через ==, switch, Equals и т.д.
название метода, возвращающего строковый литерал
Диагностика анализирует идентификатор и оценивает, насколько он связан с какими-то конфиденциальными данными. В большинстве случаев идентификатор это что-то простое типа GetPassword или myPassword. Ну и конечно же диагностика проверяет, что сам строковый литерал не пустой.
Наше правило не ругается на такие случаи (когда password = "") и работает несколько более сложным образом :)
Например, пароль может быть передан в качестве параметра в какой-нибудь метод — V5601 найдёт это. Скоро выходит новая версия, где эта диагностика будет доступна — я бы посоветовал попробовать её в деле.
Ну, например, аннотации сообщают о том, что возвращаемые значения некоторых методов должны быть использованы, иначе вызовы таких методов не имеют смысла (может, кто-то забыл присвоить или просто лишний вызов).
Например, есть замечательный метод Vector3.Normalize. В доках, кстати, написано 'Note that this function will change the current vector', хотя статическая версия этого метода (которая вроде как там и описывается) при всём желании не сможет этого сделать. Если пользователь вызвал Vector3.Normalize(vector) и при этом не присвоил результат другой переменной, то вызов не имеет смысла — скорее всего, он думал, что поменяется как раз вектор, переданный в качестве аргумента. Аннотации помогают такие штуки ловить. Без них часто нельзя быть уверенными в том, имеет ли вызов метода смысл, если результат вызова не использован (очевидно, бывают методы, возвращаемые значения которых можно не использовать).
Конечно, это лишь пример работы аннотаций, они используются не только для таких случаев.
Вот этот момент уже действительно достаточно интересный. Большое спасибо, мы обдумаем возможности доработки анализатора, чтобы он мог такое отлавливать.
ClEditInfo cei = _editVarMap[v];
if (cei == null)
{
throw new CassowaryException("SuggestValue for variable " + v + ", but var is not an edit variable\n");
}
По этому фрагменту не соглашусь. В словарь вполне можно записать null. Например,
Действительно, есть такая проблема. Дело в том, что у анализатор тут предполагает, что теоретически значение centerY_ может поменяться при вызове solver.AddConstraint. Однако человеческий глаз, конечно, легко видит тут странный момент, да. Мы подумаем над тем, как нам улучшить работу анализатора в подобных местах, спасибо за отзыв :)
Как я и говорил, чудес тут нет. Если Вам кажется, что алгоритм можно было бы как-то улучшить, то прошу поделиться этими идеями и возможно, они помогут нам сделать диагностику лучше :)
Диагностика анализирует идентификатор и оценивает, насколько он связан с какими-то конфиденциальными данными. В большинстве случаев идентификатор это что-то простое типа GetPassword или myPassword. Ну и конечно же диагностика проверяет, что сам строковый литерал не пустой.
Например, пароль может быть передан в качестве параметра в какой-нибудь метод — V5601 найдёт это. Скоро выходит новая версия, где эта диагностика будет доступна — я бы посоветовал попробовать её в деле.
Например, есть замечательный метод Vector3.Normalize. В доках, кстати, написано 'Note that this function will change the current vector', хотя статическая версия этого метода (которая вроде как там и описывается) при всём желании не сможет этого сделать. Если пользователь вызвал Vector3.Normalize(vector) и при этом не присвоил результат другой переменной, то вызов не имеет смысла — скорее всего, он думал, что поменяется как раз вектор, переданный в качестве аргумента. Аннотации помогают такие штуки ловить. Без них часто нельзя быть уверенными в том, имеет ли вызов метода смысл, если результат вызова не использован (очевидно, бывают методы, возвращаемые значения которых можно не использовать).
Конечно, это лишь пример работы аннотаций, они используются не только для таких случаев.
По этому фрагменту не соглашусь. В словарь вполне можно записать null. Например,