DM Guide 19 - История изменений

Krendelec в 11:04, 11 мая 2019

2019-05-11T11:04:00Z

Necromeme в 19:13, 10 мая 2019

2019-05-10T19:13:25Z

Architect of fates: Откат правок ZLOFENIХ (обсуждение) к версии Recei

2016-12-12T22:11:36Z

Откат правок ZLOFENIХ (обсуждение) к версии Recei

Внесённые изменения

ZLOFENIХ: clean up, removed: {{Заготовка}} (204)

2016-12-12T21:05:05Z

clean up, removed: {{Заготовка}} (204)

Внесённые изменения

Recei: Скажем честно. Ты ноунейм умеющий лишь в промтоперевод. И никакой ценности для вики не представляешь.

2015-11-19T21:04:19Z

Скажем честно. Ты ноунейм умеющий лишь в промтоперевод. И никакой ценности для вики не представляешь.

IXVI: Ты за 5 дней посмотрел, привлёк кого-то, исправил хоть что-то, или просто подставы кидаешь? Иди на хуй, не тебя звали.

2015-11-19T20:51:10Z

Ты за 5 дней посмотрел, привлёк кого-то, исправил хоть что-то, или просто подставы кидаешь? Иди на хуй, не тебя звали.

Recei: Рука ее ебал. Пожалуйста не надо переводить то, в чем ничего не понимаешь ничего. И тем более машинным переводом.

2015-11-14T20:09:58Z

Рука ее ебал. Пожалуйста не надо переводить то, в чем ничего не понимаешь ничего. И тем более машинным переводом.

IXVI: /* О порядке написания кода */ последняя правка. Хорошо бы какой-нибудь кодер проверил и упорядочил главы и содержание. Я не кодер.

2015-11-14T20:02:18Z

О порядке написания кода: последняя правка. Хорошо бы какой-нибудь кодер проверил и упорядочил главы и содержание. Я не кодер.

IXVI: /* Debugging Code */

2015-11-14T20:01:27Z

Debugging Code

IXVI: /* Типичные проблемы в больших проектах */

2015-11-14T17:23:45Z

Типичные проблемы в больших проектах

← Предыдущая версия		Версия от 11:04, 11 мая 2019
Строка 1:		Строка 1:
	{{Заготовка}}		{{Заготовка}}
−	~~{{Устарело}}~~
−
	Данная статья не совсем соответствует действительности и нуждается в новом переводе.		Данная статья не совсем соответствует действительности и нуждается в новом переводе.

← Предыдущая версия		Версия от 19:13, 10 мая 2019
Строка 1:		Строка 1:
	{{Заготовка}}		{{Заготовка}}
		+	{{Устарело}}

	Данная статья не совсем соответствует действительности и нуждается в новом переводе.		Данная статья не совсем соответствует действительности и нуждается в новом переводе.

← Предыдущая версия		Версия от 21:04, 19 ноября 2015
Строка 1:		Строка 1:
	{{Заготовка}}		{{Заготовка}}
		+
		+	Данная статья не совсем соответствует действительности и нуждается в новом переводе.
		+
	''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков. Если вы работаете в Dream Maker - внимательно прочтите её и сообщите о найденных ошибках.''		''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков. Если вы работаете в Dream Maker - внимательно прочтите её и сообщите о найденных ошибках.''

@@ Строка 1: / Строка 1: @@
 {{Заготовка}}
-''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''
+''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков. Если вы работаете в Dream Maker - внимательно прочтите её и сообщите о найденных ошибках.''
 [http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

@@ Строка 239: / Строка 239: @@
 client/Topic(T)
-:  if(T == "вступление")
+   if(T == "вступление")
-:  usr << "И вот как-то раз..."
+      usr << "И вот как-то раз..."
-:  else ..()
+   else ..()
 client/Topic(T)
-:  if(T == "подсказка")
+   if(T == "подсказка")
-:  usr << "Буквально позавчера."
+      usr << "Буквально позавчера."
-:  else ..()
+   else ..()
 В таком написании, эти два определения процедуры client/Topic(T) могут быть размещены в коде в любом месте. Если один из них будет выполнен и приведёт к значению ..() ,то другой уже не наступит. Вот в таких случаях и бывает полезно обращаться к процедуре-родителю
 <!--As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.-->
 ===Отладка кода===

@@ Строка 251: / Строка 251: @@
-===Debugging Code===
+===Отладка кода===
-Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.
+Или иначе дебаггинг(debugging).
-====Good Coding Habits====
+Ошибка начинающих программистов в том, что они слишком полагаются на компилятор. Опытные баголовы и багоюзеры знают, что если код скомпилирован, то не факт что он работает как написано. Уязвимости бывают везде.
-The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.
+Первый вызов для отладчика кода - суметь прочитать код и попробовать скомпилировать его в уме, так как его увидит машина. Возможно где-то не хватает переменных, возможно некоторые процессы ведут к нулевому значению, возможно некоторые условия невозможно выполнить в принципе. Думайте логически.
-The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.
+Второй шаг - запустить код, так чтобы он заработал. Подставить необходимые переменные и запустить его в приложении. Сервер может выявить простые ошибки и баги, но только вы можете понять что работает не так, как оно должно работать, и почему это не так. А что работает именно так как описано в коде. Поиграйте с переменными и кодом, чтобы лучше понять механизмы компиляции и работы вашего кода.
-The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.
+Затем проведите нагрузочное тестирование, попробуйте выйти за пределы допустимых параметров, указанных вами при создании объектов и фич для проекта. Как правило на этом этапе всплывают все баги и уязвимости в написанном и вы можете отловить их и пофиксить\оставить для рабочей версии проекта.
-After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.
+Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!-->
-Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!
+===="Неуловимые" баги====
 Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.
 There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.
-When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.
+When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.-->
-The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.
+Самое главное - найти в логах название процедуры, которая вызвала падение выполнения кода, а также значение переменных src и usr на момент выполнения процедуры. Процедуры могут быть показаны цепочкой вызовов - будут показаны обращающиеся к этой и вызванной этой процедурой процедуры.
-If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.
+Также вы можете воспользоваться макросом DEBUG, описанным выше для отлова багов и точным вычислением их месторасположения в коде исполняемого файла.
-One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:
+world.log << "[__LINE__]: myvar = [myvar]"
-world.log << "[__LINE__]: myvar = [myvar]"
+Отладка кода проводится как при отдельных случаях падения кода(и тогда удобнее пользоваться примерами приведёнными выше), так и по всем исполняемым строкам и файлам при финальной диагностике. В последнем случае вы можете пользоваться следующими макросами:
-Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.
+<!--Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.-->
 : #ifdef DEBUG
@@ Строка 291: / Строка 300: @@
 : #define debug null
 : #endif
-Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.
+Вывод информации на отладку будет осуществляться, но он будет игнорироваться до тех пор, пока вы не используете макрос #DEBUG.
-This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.
+This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.-->

@@ Строка 219: / Строка 219: @@
 При разработке большого проекта, хотя бы один из участников(а желательно все) должен быть ознакомлен с тем, что делает каждый из написанных модулей и какое у него применение. Хорошим тоном считается делать простое и понятное описание и название для каждого модуля.
-<!--Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.-->
+<!--Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.
-When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.
+When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.-->
@@ Строка 247: / Строка 247: @@
        usr << "Буквально позавчера."
     else ..()
-В таком написании, эти два определения процедуры client/Topic(T) могут быть
+В таком написании, эти два определения процедуры client/Topic(T) могут быть размещены в коде в любом месте. Если один из них будет выполнен и приведёт к значению ..() ,то другой уже не наступит. Вот в таких случаях и бывает полезно обращаться к процедуре-родителю
-As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.
+<!--As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.-->