Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

New answers tagged

2

Finally, I am well aware that the value of the gravitational constant 𝐺 is 6.67408×10−11 and not 0.5, as I have implemented it here; using the correct value of 𝐺 results in a simulation that runs far too slow to appreciate. It is strange to me that you chose to change the gravitational constant rather than simply choosing a different time step; can you ...


1

Your code is a nightmare. This is mainly because all the jump labels have very similar names: L0, l0, j0, J0, J1. What the hell do they mean? Please use more descriptive names for them. The assembly code you are using does not make use of any advanced features of machine language. Instead, only the variable names get worse. It's far easier for a human ...


4

Just reviewing the FileGroup class. 1. Review The name FileGroup does not convey the intended purpose of the class (namely, that all the files in the group share an inode). A name like InodeFiles would be better. The intention of the class is that all the files share an inode. But the class itself does not check this: it relies on the caller to do so. It ...


2

Gravitational Constant In your description you mention the gravitational constant is 0.5 for performance reasons, in the code it is actually 0.1. This Pointer There are times when the this pointer is necessary, but it is not necessary in the code under review (EntryPoint.cs, Body.cs and BodySystem.cs). Variable Names To some extent this is personal ...


2

Afterthought / tldr; If you start naming your methods & variables descriptively, using the suggestions below & finding more information/examples online it will be a huge 'level up' in your programming. Everything else will become easier. General coding standards Use static final variables for messages. Alternatively these could be taken from a ...


2

When declaring variables, move the declaration towards the first usage. Moving declaration away from usage makes it harder to understand how your variables are actually being used. When declaring variables, prefer final whenever possible. If you know that a value won't change, it's one less thing to keep track of as you're trying to read and understand code. ...


7

Nice job using ENUMS 👍 I'm going to try to do the Code Review top-down. Don't shorten variable names The compiler doesn't care how long names are. I'm guessing the 'hm' in hmInARowToWin stands for 'howMany'. So it should be changed to howManyInARowToIn or amountInARowToWin. Use 'final' keyword when possible Your scanner object is never going to change....


4

Use Intention-Revealing Names Based on naming alone, the intent of the Calc() method is not clear. As the reader of your code, I have to look at the implementation details of this method to understand what we are calculating. Method Characteristics Pay careful attention to your method signatures. Do ExitProgram() and Calc() need to both be static? If ...


2

Recusion Abuse This does not seem to be a naturally recursive problem and using recursion here causes more issues than it is worth: If the user enters too many invalid inputs, they can blow the stack. If a user errors out by inputting an incorrect password, they have to re-select their intent to login before they are able to try again. Control flow is not ...


0

Edward wrote: Jumps often take longer, and jumps without explicitly named targets are a recipe for future frustration. Yes, I remember the days when I used to spend hours just for that very reason, but it's become such a habit now, that whenever I anticipate a change, if there isn't an explicit reference I look up in code to see where that register was ...


0

As a result of a alternate method deliniated by Edward, overhead has been reduced from 168 bytes to 56 a 300% saving. ~$ nasm -felf64 appname.asm -oappname.o ~$ ld appname.o -oappname USE64 TIOCGWINSZ equ 0x5413 STDOUT_FILENO equ 1 sys_ioctl equ 16 sys_exit equ 60 global _start section .text ; =...


3

Here are some things that may help you improve your program Use consistent formatting The code as posted has irregular indentation, making it not so easy to read. Assembly language programs are typically very linear and neat. Also, I personally don't use tab characters in my code so that it looks the same everywhere (including printing), but that's a ...


3

A code-size optimization If you move the mov edi, Metrics instruction to just below the FindMatch label and thus have it repeat with each iteration, you can remove 4 instructions from the code. I've marked these with an exclamation mark: xor edx, edx mov ecx, edx FindMatch: mov edi, Metrics ;Restore it from here ...


Top 50 recent answers are included