Where the 400-line pull request rule came from, and what the newer data says

·7 views

A common online rule says pull requests should stay under 400 lines, but tracing it leads to a 2006 study by SmartBear, a code review tool vendor, run with a Cisco team. That study reviewed about 2,500 reviews covering 3.2 million lines of code, finding defect density dropped once reviews exceeded roughly 200 lines. The original research measured reviewer effectiveness rather than how risky a change was, and it reflects a single team, product, and pre-commit tooling setup. Newer vendor benchmarks from LinearB and Graphite offer different size guidance, with Graphite suggesting a median of about 50 lines, and the two sets of figures measure different parts of the same distribution. Both sources sell tools that track these metrics, so the numbers are best treated as a starting point rather than a fixed rule.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Guide Explains Audio Formats and Quality Settings Behind Voice AI Output

Voice AI tools such as text-to-speech engines, voice cloning, and speech-to-text APIs are spreading into everyday apps, making audio fidelity more important. The guide outlines common formats including WAV, MP3, OGG, Opus, and FLAC, comparing their compression approaches and typical uses. It also explains key quality parameters like sample rate, bit depth, codec, and channel count, along with their trade-offs for file size and sound quality. Using ElevenLabs as an example, it shows how developers can request specific audio settings through the API. Recommendations suggest Opus for real-time voice and higher sample rates for podcasts or video.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

LLM reranker silently did nothing: token limit cut off replies, fallback hid the failure

A developer's text-to-SQL table selector included an optional LLM reranker that appeared to have no effect on results. Logging showed the model was being called but returned no answer, because newer Claude models spend tokens on internal reasoning and exhausted a 120-token limit before producing output. The reranker's error handling caught the failure and silently returned the original order, so existing tests passed while the feature was broken. The fix raised the token limit to 1024, added a test that fails below 512 tokens, and logged whether the model answered on each question. On public Spider and BIRD benchmarks, the reranked version placed the correct tables in the top five for substantially more questions than the baseline, though results reflect one model and measure table retrieval rather than final SQL accuracy.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Fare Calendar Uses Gemma 4 and Chronos to Show Cheapest Travel Days for Agents

A developer built a Fare Calendar for a B2B travel agency portal, letting sub-agents see the lowest fare for each date before running searches. The tool draws on the portal's own server logs, marking fares actually seen in the last three days and using model estimates with likely ranges for unsearched dates. Gemma 4 was used to write field mappings that parse fare data from 13 supplier formats, with code validating each mapping against real responses before use. The system runs on the agency's own hardware, plugs into the portal as a web component, and covers 557 routes with forecasts for 23,626 dates. Fares are labelled indicative, and agents reprice live before booking.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Shared Sequencer : comment un ordonnancement partagé réduit la centralisation des Layer 2

Le shared sequencer est une architecture dans laquelle plusieurs chaînes Layer 2 confient l'ordonnancement de leurs transactions à un même ensemble d'opérateurs. Contrairement aux séquenceurs propriétaires, l'autorité sur la validation est répartie entre plusieurs entités indépendantes plutôt que concentrée sur une seule. Ce modèle vise à limiter les points de défaillance et la capacité de contrôle unique tout en préservant la rapidité de traitement. Le processus repose sur la sélection des opérateurs, un consensus sur l'ordre des transactions, puis la signature et la publication des blocs. Des mécanismes de résolution des conflits, avec pénalités et rollback partiel, complètent l'approche.

0 comments Read more at DEV Community