cpp
/
3DSoftwareRenderer-DFSPR
의 미러 https://github.com/Dawoodoz/DFPSR.git


			
				
					
						
						
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556
							<HTML>
	<BODY>
		<link rel="stylesheet" type="text/css" href="PageStyle.css">
<P>		<IMG SRC="Images/Title.png">
<P>		<A href="../Manual.html">Back to main page</A>
<P>		<b>Code convention for David Forsgren Piuva's Software Renderer</b>
<P>		To keep the style consistent, the style being used in the library is explained in this document.
<P>	<IMG SRC="Images/Border.png">
<P>		1. Use common sense!
<P>		If it looks wrong to human readers then it's wrong.
<P>		Don't defeat the purpose of any rule by taking it too far.
<P>	<IMG SRC="Images/Border.png">
<P>		2. Don't use iterators when there is any other way to accomplish the task.
<P>		You can't write efficient algorithms without knowing the data structures.
<P>	<IMG SRC="Images/Border.png">
<P>		3. Tabs for indentation then spaces for alignment.
<P>		It's the best of both worlds by both having variable length tabs
<P>		and correct alignment that works between lines of the same indentation.
<P>	<IMG SRC="Images/Border.png">
<P>		4. No dangling else, use explicit {} for safety.
<P>		Otherwise someone might add an extra statement and get random crashes.
<P>	<IMG SRC="Images/Border.png">
<P>		5. No hpp extensions, use h for all headers.
<P>		Could be either way, but this library uses *.h for compact naming, so keep it consistent.
<P>	<IMG SRC="Images/Border.png">
<P>		6. C-style casting for raw data manipulation and C++-style for high-level classes.
<P>		When using assembly intrinsics and raw pointer manipulation to alter the state of bits,
<P>		verbose high-level abstractions only make it harder to count CPU cycles in your head.
<P>		Always use the tool that makes sense for the problem you're trying to solve.
<P>		C++ style is for things that are abstracted on a higher level.
<P>		C style is for when a byte is just a byte and you just want to manipulate it in a specific way.
<P>	<IMG SRC="Images/Border.png">
<P>		7. Don't call member methods with "this" set to nullptr.
<P>		This would be undefined behaviour and may randomly crash.
<P>		Use global functions instead. They allow checking pointers for null
<P>		because they are explicit arguments declared by the programmer.
<P>	<IMG SRC="Images/Border.png">
<P>		8. Avoid using STD/STL directly in SDK examples.
<P>		Exposing types from the standard library should be done using an alias or wrapper in the dsr namespace.
<P>		This allow replacing the standard library without breaking backward compatibility.
<P>		The C++ standard libraries have broken backward compatibility before and it can happen again.
<P>	<IMG SRC="Images/Border.png">
<P>		9. Don't abuse the auto keyword everywhere just to make it look more "modern".
<P>		Explicit type safety is what makes compiled languages safer than scripting.
<P>	<IMG SRC="Images/Border.png">
<P>		10. No new line for opening brackets.
<P>		Makes the code more compact and decreases the risk of copy-paste errors.
<P>	<IMG SRC="Images/Border.png">
<P>		11. Don't fix the style of someone else's code if you can easily read it.
<P>		Especially if there's no style rule explicitly supporting the change.
<P>		Otherwise style changes will defeat the purpose by introducing more version conflicts.
<P>	<IMG SRC="Images/Border.png">
<P>		12. Don't change things that you don't know how to test.
<P>	<IMG SRC="Images/Border.png">
	</BODY>
</HTML>