Индекс пригодности для обслуживания
Если я вас правильно понимаю, вы хотите сделать что-то по следующему:
from dataclasses import dataclass
# the type doesn't matter, this is just an example
@dataclass
class A:
value: int
lst = [A(1), A(2), A(3), A(4), A(5), A(6)]
# you can check for any condition here
no_evens = sum(item.value % 2 == 0 for item in lst)
print(f"there are {no_evens} even numbers in the list")
На этот вопрос уже ответят здесь . Но я хотел бы добавить кое-что:
Вы запрашиваете список по двум причинам:
- Сколько объектов соответствует, и
- сумма их значений (
pixel.pointв вашем коде).
Это потребует двух итераций вместо одной - просто используйте один цикл for.
3 ответа
Это зависит, как "Индекс Пригодности для обслуживания" вычисляется. Это не кажется мне как что-то, что работало бы через языки просто, потому что языки так отличаются.
Могло бы казаться разумным сделать, простое выдерживает сравнение "количества строк на функцию", но что происходит, когда Вы пытаетесь сравнить код C, который полон указателей или кода C++, полного шаблонов, или C# с запросами LINQ или Java с дженериками?
Все те вещи влияют на пригодность для обслуживания, но не могут измеряться никаким значимым межъязыковым способом, поэтому как можно когда-либо сравнивать числа между 2 языками?
I don't think you can put a number on how easy a piece of code will be for a developer to maintain.
Different people will look at the same code and interpret it in their own way, depending on experience, culture, reading comprehension, etc.
That being said, metrics would definitely be different across technologies. You're looking at completely different syntax, conventions, terminology, etc. How can you quantify the difficulty difference between low level mainframe code and a high level language like Java or C#?
I think metrics are good for one thing, and one thing only: guidelines. In terms of code quality, I don't think they should be used for anything other than describing a code base. They should not be used as a determining factor of difficulty or "grok-ability".
Это объяснение значения значения индекса ремонтопригодности.
Вскоре это
MI = 171 - 5.2*ln(Halstead Volume) - 0.23*(Cyclomatic Complexity) - 16.2*ln(Lines of Code)
масштабируется от 0 до 100.
Как легко видеть, эта метрика может использоваться для любого процедурного языка.