DictionaryForumContacts

   Russian
Terms for subject Programming containing если не было | all forms
RussianEnglish
в синхронном режиме передачи для каждого элемента в потоке данных определяется максимальная задержка сквозной передачи. Если элемент данных был передан значительно быстрее максимально допустимой задержки, это не важноin synchronous transmission mode, there is a maximum end-to-end delay defined for each unit in a data stream. Whether a data unit is transferred much faster than the maximum tolerated delay is not important (см. Distributed systems: principles and paradigms / Andrew S. Tanenbaum, Maarten Van Steen 2007)
если методы ликвидации последствий сбоев не могут быть обобщены для работы со многими типами искажений, лучше всего направлять силы и средства на предупреждение ошибокUnless fault-correction functions can be generalized to correct many types of damage, fault avoidance is a better investment ("Software Reliability: Principles and Practices" by Glenford J. Myers (1976) ssn)
если ни один из операндов не является одномерным массивом, то тип результата должен быть известен из контекстаif neither operand is a one-dimensional array, the type of the result must be known from the context (см. IEЕЕ Std. 1076-87. IEЕЕ Standard VHDL. Language Reference Manual ssn)
если ни одна кнопка не нажата, электродвигатель должен быть включен или выключен в зависимости от того, в каком состоянии он находился до этогоwith neither button pressed, the motor could be running or stopped depending on what occurred last (см. E.A. Parr Programmable Controllers – An Engineer's Guide)
Например, данная обязательная принадлежность может дополнительно означать, что принадлежность является фиксированной, т.е. если объект связан с целевым объектом в ассоциации, он не может быть повторно связан с другим целевым объектом в той же ассоциацииfor example, a particular mandatory membership may additionally imply that the membership is fixed, i.e. once an object is linked to a target object in the association it cannot be reconnected to another target object in the same association (см. Maciaszek, L.A.: Requirements Analysis and System Design, 3rd ed. 2007)
настоящий программист не документирует программу – если её было тяжело написать, то и понять её должно быть нелегкоReal programmers don't document. If it was hard to write, it should be hard to understand (шутка)
настоящий программист не документирует программу — если её было тяжело написать, то и понять её должно быть нелегкоReal programmers don't document. If it was hard to write, it should be hard to understand (шутка)
Никто не ожидает, что мост будет перемещён на десять метров после того, как он был построен. Точно так же не следует ожидать, что программный продукт успешно выполнит различные задачи после того, как будет создан. Если это то, что нам нужно, тогда программное обеспечение создано удачноnobody expects a bridge to be moved by ten meters after it has been built. Similarly, nobody should expect a software product to happily perform different tasks after it has been built. If this is what is expected then the software has not failed (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering)
но для простоты в данном обсуждении мы будем и далее, если это не приведёт к путанице, опускать слово "образец"for simplicity, this discussion will continue omitting the word "pattern" when there is no risk of confusion (см. Object-Oriented Software Construction second edition by Bertrand Meyer)
Структурное проектирование – нечто вроде упражнения в управлении зависимостями модулей. Модуль A зависит от модуля B, если изменения в модуле B могут потребовать изменений в модуле A. Важно, чтобы эти зависимости не противоречили брандмауэрам зависимостей Мартин, 2003. В частности, зависимости не должны быть между несоседними уровнями и не должны создавать циклыArchitectural design is an exercise in managing module dependencies. Module A depends on module B if changes to module B may necessitate changes to module A. It is important that dependencies do not cross dependency firewalls Martin, 2003. In particular, dependencies should not propagate across non-neighboring layers and must not create cycles (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering ssn)